Saga Transactions
Coordinate a long-running workflow with local commits and explicit compensation.
2–5 minute refresher
Coordinator
1 · PREPARE↓2 · COMMIT / ABORT
Inventoryready ✓
Paymentready ✓
Ledgerready ✓
Commit locally → continue → compensate completed steps on failure
30second
refresher
refresher
A saga breaks one cross-service transaction into local transactions. Each committed step has a compensating action, and a durable orchestrator or event choreography drives the workflow toward completion or repair.
What problem does it solve?
Long-lived work across independent services cannot safely hold database locks or depend on every participant being available at once.
How it works
- Define the invariant and durable workflow state.
- Execute one idempotent local transaction.
- Record the outcome and next command atomically.
- Retry ambiguous steps with stable operation IDs.
- On terminal failure, run compensations in a deliberate order and escalate irreparable cases.
Decision guide
Key trade-offs
| Choice | What you gain | What it costs |
|---|---|---|
| Orchestration | Visible state and centralized recovery | Coordinator complexity |
| Choreography | Loose service coupling | Harder global reasoning |
| Compensation | Progress without global locks | Temporary inconsistency and business edge cases |
What happens if?
A compensation also fails
The workflow remains in a durable recovery state and retries safely. After a policy limit, route it to human or automated reconciliation with complete history; never silently declare success.
Where it appears
- Order fulfillment
- Travel booking
- Payment workflows
- Temporal-style orchestration
Senior interview modeWhen would you choose a saga instead of two-phase commit?Show answer
Choose a saga for long-running, cross-service work where temporary inconsistency and explicit compensation are acceptable and participant availability matters more than one atomic commit point.