A saga manages a business transaction that spans multiple services as a sequence of local transactions. If a step fails, the saga runs compensating transactions to undo prior steps — there is no distributed rollback.
Two-phase commit across services is slow, locks resources, and couples availability. Sagas give eventual consistency without distributed locks.
Services react to each other's events; no central coordinator.
Order ─OrderCreated→ Payment ─PaymentDone→ Inventory ─Reserved→ Shipping
◀───────── (on failure, each emits a compensating event) ─────────
An orchestrator tells each service what to do and reacts to results.
┌───────────── Saga Orchestrator ─────────────┐
▼ ▼ ▼ ▼
reservePayment reserveStock createShipment (on fail: compensate all)
| Aspect | Choreography | Orchestration |
|---|---|---|
| Coordination | Distributed (events) | Centralized |
| Coupling | Looser | Coordinator knows flow |
| Visibility | Hard to follow | Easy to trace |
| Best for | Simple, few steps | Complex, many steps |
Compensations must be idempotent and handle the case where the original step partially succeeded. Design them carefully.
Sagas are how you keep data consistent across services without the cost and coupling of distributed transactions.
Choosing choreography vs orchestration trades simplicity for visibility: events scale loosely but get tangled, while an orchestrator centralizes complex logic at the cost of one more component to run.
A library of IT interview questions with detailed answers — from Junior to Senior.
Donate