System DesignEasy
What is the SAGA pattern and when would you use it?
The SAGA pattern breaks a single business transaction that spans multiple services into a sequence of local transactions, each owned by one service. If any local transaction fails, the saga executes compensating transactions in reverse order to undo prior steps.
When to use it
- You have a workflow that touches 3+ microservices, each with its own database
- A traditional database transaction (2PC) is impractical or rejected for scaling reasons
- You can accept eventual consistency for a short window (seconds to minutes)
- Each step is reversible via a compensating operation
Concrete example — order checkout
1. Reserve inventory → compensation: release inventory
2. Charge payment → compensation: refund payment
3. Schedule shipping → compensation: cancel shipping
4. Send confirmation → compensation: send cancellation
If "charge payment" fails after "reserve inventory" succeeded, the saga calls "release inventory" → the system returns to a consistent state.
What it gives you
- Reliable cross-service workflows without distributed locking
- Audit trail by design (saga state log = audit log)
- Independent service scaling — no shared lock manager
What it costs you
- Compensating logic doubles your code — every "do X" needs an "undo X"
- Eventual consistency window — readers may see intermediate states
- Idempotency is non-negotiable — every step must be safely retryable
- Some operations are not compensable — once an email is sent, you can't unsend it
When NOT to use it
- Workflow lives inside a single service / DB — use a normal DB transaction
- Read-only operations — there's nothing to compensate
- Hard requirement: no observer ever sees intermediate state — use 2PC or rearchitect
Real-world fit
E-commerce checkout, travel booking (flight + hotel + car), insurance claims, multi-account fund transfers, order fulfilment workflows.