Saga Pattern
Saga pattern — a way to ensure consistency across distributed transactions without 2PC (two-phase commit). Breaks the transaction into local steps + compensation actions (undo a step if the next fails). Two styles: choreography (events between services) and orchestration (central coordinator). Popular in microservices for purchase flows: order → payment → shipping → confirm, rollback on any failure.
Below: details, example, related terms, FAQ.
Details
- Choreography: services listen to events, react. Loose coupling, harder to debug
- Orchestration: saga orchestrator manages flow (Netflix Conductor, Temporal, AWS Step Functions)
- Compensation: every step has an inverse. Payment → RefundPayment
- Idempotency: steps must be idempotent on retry
- Failure modes: partial completion, retry storms
Example
Saga: PlaceOrder
1. ReserveInventory → compensation: ReleaseInventory
2. ChargePayment → compensation: RefundPayment
3. ShipOrder → compensation: CancelShipment
On failure at step 3 → run compensations 2, 1 in reverseRelated Terms
Learn more
Frequently Asked Questions
Saga vs 2PC?
2PC (XA transactions) — synchronous, locks resources, does not scale, rarely in cloud. Saga — async, eventual consistency, no locks.
Choreography or orchestration?
Choreography for 2-3 services. Orchestration for complex flows (5+ steps) — easier to debug and modify.
Tool recommendations?
Temporal (temporal.io) — modern, durable execution. Netflix Conductor. AWS Step Functions. For simpler — just messages via Kafka/RabbitMQ.