Saga pattern
Managing transactions between microservices
About me
- ~15yrs writing (and reading) code
- FLOSS supporter
- Kids' football coach
- Former:
- Developer Advocate @ Google
- Teacher
- Conference speaker
- Current:
- Lead developer @ Brandon Group
- MockK maintainer
"a software design pattern is a general, reusable solution to a commonly occurring problem within a given context"
(Wikipedia)
The problem
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
A key component
(or ZeroMQ, Kafka, Amazon MQ o SQS, Google Cloud Pub/Sub, ActiveMQ...)
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 |
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 Eng
By Mattia Tommasone
