Saga pattern
Managing transactions between microservices
"a software design pattern is a general, reusable solution to a commonly occurring problem within a given context"
(Wikipedia)
The problem
1: Buy goods
Marketplace
Brandon Group
2: Sales Order
3: Purchase Order
4: Confirmation
5: Ship goods
6: Shipment order
7: Ship goods
7: Tracking info
8: Update Order
Customer
Supplier
Logistic partner
The problem (cont.)
- "Brandon group" is actually a set of different (micro) services
- The state of an order depends on several transactions between different services and external entities
- Transactions may not be instant or synchronous
The easy solution
However...
Introducing some key concepts:
Saga
-
A sequence of steps, each of which is a local transaction in a microservice
-
The gold saint in the constellation of Gemini
Problem
Compensating transaction
Allows to rollback single steps of the saga
Semantic lock
Prevents unsupported state transitions from happening by using a state machine
2 possible versions
Choreography
- Each microservice can emit an event
- Each microservice can subscribe to an event
Orchestration
- A component of the architecture, the orchestrator, sends commands to the others
- Each microservice receives commands from the orchestrator and sends responses
Comparison
| Choreography | Orchestration |
|---|---|
| Loose coupling | Tight coupling |
| One format for events | Different formats for events |
| Fully decentralized | Orchestrator as a possible bottleneck |
| Business process split on different applications | Business process handled almost totally by the orchestrator |
Marketplace
Customer
Supplier
Logistic partner
Karl
Markus
Jimbo
Bridget
How we do it (simplified)
Our headaches
- What if the orchestrator never receives a response?
- What if an object is in an inconsistent state?
Bonus: your cloud provider already supports orchestration!
- AWS Step Functions
- Google Workflows
- Azure logic apps
Questions?
Saga Pattern Google
By Mattia Tommasone
