Architecture
Design Saga Pattern
The saga pattern manages distributed transactions as a sequence of local transactions with compensating actions. If any step fails, compensating transactions undo previous steps.
- Problem — Distributed transactions across microservices
- Solution — Compensating transactions for rollback
- Modes — Choreography (events) vs Orchestration (coordinator)
Sagas are the practical alternative to 2PC: trade immediate consistency for eventual consistency with compensation.
What Is a Saga?
DfSaga Pattern
A saga is a sequence of local transactions T1, T2, ..., Tn. Each Ti has a compensating transaction Ci. If T3 fails, the saga executes C2, C1 to undo T2, T1. This ensures the system reaches a consistent state without distributed locks.
Saga Execution
Choreography vs Orchestration
DfChoreography
Each service listens for events and decides what to do next. No central coordinator. Services emit events when they complete their step. Simple but hard to track overall flow.
DfOrchestration
A central saga orchestrator coordinates all steps. The orchestrator tells each service what to do and handles compensations. Easier to understand and debug.
| Aspect | Choreography | Orchestration |
|---|---|---|
| Coupling | Loose (events) | Tight (direct calls) |
| Visibility | Hard to trace | Easy to trace |
| Complexity | Distributed | Centralized |
| Single Point of Failure | None | Orchestrator |
| Best For | Simple flows | Complex workflows |
Compensating Transactions
DfCompensating Transaction
A compensating transaction reverses the effect of a completed transaction. It's not a true undo—it's a new transaction that produces the same net effect. For example, "refund payment" compensates "charge payment."
Compensating transactions can fail. Design retry mechanisms and manual intervention queues for failed compensations. The system should eventually reach consistency, even if some steps require human intervention.
Saga State Machine
Saga State Transition
Here,
- =Saga initiated
- =Executing steps
- =Rolling back
Practice Exercises
- Design: Implement an order saga with: reserve inventory, charge payment, create shipment. What happens if payment fails?
- Compensation: Design a compensating transaction for "send email notification."
- Monitoring: How would you monitor saga progress and detect stuck sagas?
- Recovery: Design a recovery mechanism for sagas stuck in COMPENSATING state.
Key Takeaways:
- Sagas replace distributed transactions with local transactions + compensation
- Choreography uses events (loose coupling); orchestration uses a coordinator (visibility)
- Compensating transactions are not true undos—they're new transactions
- Design for compensation failures with retry and manual intervention
- Saga state machine tracks progress and enables recovery
What to Learn Next
-> Outbox Pattern Reliable event publishing.
-> Idempotency Safe compensation semantics.
-> Circuit Breaker Saga step resilience.
-> Retry Patterns Retry in saga steps.
-> Design Amazon Checkout saga.
-> Design Uber Trip lifecycle saga.