Serverless microservices allow building scalable and resilient applications from small, isolated services using AWS Lambda and API Gateway. Each microservice owns its own data in a decentralized data store like DynamoDB. API Gateway acts as a front door and handles authentication, authorization, and throttling. Lambda provides immutable function versions and aliases for deployments. While this makes applications highly available and scalable, it introduces challenges around transactions and data consistency. The document proposes using techniques like correlation IDs, rollback functions, DynamoDB streams, and a transaction manager to handle errors and rollbacks in a serverless environment.

1. © 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Olivier Klein – Emerging Technologies Solutions Architect, Asia Pacific
September 2016
Serverless Microservices
Build Scalable, Fault-­Tolerant and Transaction-­Safe Microservices on AWS

2. Microservices advocate creating a system
from a collection of small, isolated services,
each of which owns their data,
scalable and resilient to failure

3. How to Build Application Backends?
Back-­end logic DatabaseBrowser
/Mobile

4. How to Build Serverless Microservices?
AWS
Lambda
Amazon API
Gateway
Amazon
DynamoDB
Microservice

5. How to Build Serverless Microservices?
AWS
Lambda
Amazon API
Gateway
Amazon
DynamoDB
Microservice 1
Microservice 2
Microservice N
...

6. Amazon API Gateway
• Create, publish, maintain, monitor and
secure RESTful APIs
• Powered by our content delivery
network via 61 global edge locations
• Provides DDoS protection and
throttling capabilities
• Multiple API stages which you define
(e.g. dev, test, prod)
AWS Lambda
Amazon API
Gateway
Amazon EC2
AWS API
On-­prem Server

7. Amazon API Gateway: Authorisation
Amazon API
Gateway
• Allows unauthenticated requests, or
authorises via AWS IAM
• Amazon Cognito or AWS STS for
temporary credential generation
• API Keys available to monitor
individual app calls
• You can create API Key specific
throttling and usage plans
Basic – 5 TPS
Premium – 100 TPS
Power – No throttling
API Keys – Usage Plans
Amazon
Cognito
AWS IAM

8. How About Deployments?

9. AWS Lambda: Versioning
• Immutable versions of functions
• Per version configuration
• Per version Cloudwatch metrics
• Cloudwatch Logs contain version
attribute
• Aliases to “label” a version release
• $LATEST contains latest code

10. $LATEST(95) STABLE TESTING
94 X
93 X
92
Update Alias to Deploy

11. $LATEST(95) STABLE TESTING
94 X X
93
92
Update Alias to Deploy

12. API Stages

13. API Gateway Stage Variables

14. API Gateway Stage Variables

15. API Gateway Lambda Custom Domain
/prod/Resources FunctionName:stable https://api.example.com
/dev/Resources FunctionName:$LATEST https://dev.example.com
/qa/Resources FunctionName:qa https://qa.example.com
Pin your Environment with Stage Variables

16. Serverless Microservices
AWS
Lambda
Amazon API
Gateway
• Highly available
• Scalable
• Fault tolerant
• Cost effective
• Secure
• BUT: Stateless!
Microservice
?

17. Challenge: Centralised Database
user-­svc account-­svccart-­svc
DB
• Applications often have a
monolithic data store
• Difficult to make schema
changes
• Technology lock-­in
• Vertical scaling
• Single point of failure

18. Centralised Database – Anti-­pattern
• Applications often have a
monolithic data store
• Difficult to make schema
changes
• Technology lock-­in
• Vertical scaling
• Single point of failure
user-­svc account-­svccart-­svc
DB

19. Decentralised Data Stores
account-­svccart-­svc
DynamoDB RDS
user-­svc
ElastiCache RDS
• Polyglot persistence
• Each service chooses it’s
data store technology
• Low impact schema changes
• Independent scalability
• Data is gated through the
service API

20. CAP Theorem
It is impossible for a distributed computer system to
simultaneously provide all 3 of the following guarantees:
• Consistency
• Availability
• Partition Tolerance
à In the presence of network partition we need to choose
between consistency and availability

21. Challenge: Transactional Integrity
• Polyglot persistence generally translates
into eventual consistency
• Asynchronous calls allow non-­
blocking, but returns need to be handled
properly
• How about transactional integrity?
• Event-­sourcing – Capture changes as
sequence of events
• Staged commit
• Rollback on failure
ERROR
STATE?
ROLLBACK?

22. Let’s try a Demo – Online Commerce
• Online commerce with microservices to
• Checkout a cart
• Collect payment
• Warehouse Management
• Shipment
• High volume site, out of stock errors, credit
card payments with risk cut-­off (< 100 USD)
• Demonstrate successful and failing
transactions with graceful rollback

23. Best Practice: Use Correlation IDs
09-02-2015 15:03:24 ui-svc INFO [uuid-123] ……
09-02-2015 15:03:25 catalog-svc INFO [uuid-123] ……
09-02-2015 15:03:26 checkout-svc ERROR [uuid-123] ……
09-02-2015 15:03:27 payment-svc INFO [uuid-123] ……
09-02-2015 15:03:27 shipping-svc INFO [uuid-123] ……
ui-­svc
catalog-­
svc
checkout-­
svc
shipping-­
svc
payment-­
svc
request correlation id:
“uuid-­123”
correlation id:
“uuid-­123”

24. Best Practice: Microservice Owns Rollback
• Every microservice should expose
it’s own “rollback” method
• This method could just rollback
changes, or trigger subsequent
actions (e.g. send notification)
• If you implement staged commit,
also expose a commit function
Microservice
Function 1
Rollback
Commit
(optional)

25. Event-­Driven: DynamoDB Streams
• If async, consider event-­driven
approach with DynamoDB Streams
• Don’t need to manage function
execution failure, DDB Streams
automatically retries until successful
• “Attach” yourself to the data of
interest
• Kinesis, SQS, SNS also possible
Microservice

26. Challenge: Report Errors / Rollback
• What if functions fail? (business logic
failure, not code failure)
• Create a “Transaction Manager”
microservice that notifies all relevant
microservices to rollback or take action
• DynamoDB is the trigger for the clean-­up
function (could be SQS, Kinesis etc.)
• Use Correlation ID to identify relations
mm-­svc
Transaction
Manager
Function
DDB Streams
API Call
Error Table

27. Challenge: Report Errors / Rollback
ERROR
DynamoDB
Error Table
Transaction
Manager
Function
Kinesis
Error Stream
SQS
Error Queue
Rollback(co
rrelation-­id)
Rollback(co
rrelation-­id)
Rollback(co
rrelation-­id)
Rollback(co
rrelation-­id)

28. Challenge: Code Error
• Lambda execution error because of
faulty / erroneous code
• Leverage Cloudwatch Logs to
process error message and call
transaction manager
• Set Cloudwatch Logs metric filter
to look for error/exception and call
Lambda handler upon alarm state
ui-­svc
Cloudwatch
Logs
Cloudwatch
Alarm
Transaction
Manager
Function

29. Beware: Stream Model with AWS Lambda
• DynamoDB Streams and Kinesis streams directly work
with AWS Lambda, however AWS Lambda needs to
acknowledge processing the message correctly
• If Lambda fails to process the message, the stream
horizon will not be moved forward, creating a “jam”
• Solution: Monitor AWS Lambda Error Cloudwatch
Metric and react when error rate of same “Correlation ID”
keeps increasing

30. MDM – Keep Data Consistent
Databases
AWS Lambda
“Cleanup”
Function
Cloudwatch
Scheduled Event
• Perform Master Data Management
(MDM) to keep data consistent
• Create AWS Lambda function to
check consistencies across
microservices and “cleanup”
• Create Cloudwatch Event
to schedule the function
(e.g. hourly basis)

31. Final Thoughts
• Use Amazon API Gateway to build a front-­door to all your
microservices (AWS Lambda, Docker, EC2 etc.)
• Use polyglot persistence to avoid bottlenecks, schema
issues and allow independent scalability (and cache)
• Embrace eventual consistency and design fault-­tolerant
business processes which can recover
• Monitor your environment and cleanup whenever
necessary (automation is your friend!)

32. Thank You!