Saga Pattern and Distributed Transactions
A single ACID transaction cannot span multiple services or databases, yet a business operation often must (place order → reserve inventory → charge card → ship). A saga models that operation as a sequence of local transactions, each with a compensating action that semantically undoes it if a later step fails. You trade atomicity for eventual consistency plus explicit rollback logic.
Two-phase commit (2PC) gives true distributed atomicity but blocks: a coordinator holds locks across services and a coordinator failure can stall everyone, so 2PC scales poorly and is avoided in microservice and high-availability systems. Sagas relax the guarantee — each step commits independently and visibly, and failures are handled by running compensations rather than rolling back a global lock. Source: Garcia-Molina & Salem, Sagas, 1987
Two coordination styles
| Style | How | Pros | Cons |
|---|---|---|---|
| Choreography | Each service reacts to events and emits the next; no central brain | Loosely coupled, no SPOF | Hard to see the whole flow; cyclic dependencies |
| Orchestration | A central orchestrator tells each service what to do next | Explicit, observable, easy to change | Orchestrator is a dependency to run/scale |
Choreography fits short sagas; orchestration fits long or complex ones where you need to see the flow. The orchestrator is naturally a durable execution workflow.
Compensation
Compensation is semantic undo, not rollback: you cannot un-send an email, so you send a correction; you cannot un-charge instantly, so you refund. Compensations must be idempotent and ideally commutative, because retries and out-of-order delivery are normal (see Idempotency and Exactly-Once Processing).
Design implications
- No isolation. Intermediate saga states are visible to other transactions (an order exists before it is paid). Use semantic locks or status flags to manage anomalies.
- Forward vs backward recovery. Some steps retry until they succeed (forward); others trigger compensation (backward). Decide per step.
- Every step needs a compensation (or a reason it does not, e.g. read-only). Designing the undo is half the work.
- Pairs with event sourcing. Saga progress is naturally an event log; the events drive both the next step and observability.
Architecture Position
| Axis | Value |
|---|---|
| Family | Distributed systems primitives |
| Boundary owned | Business transaction split into local steps plus compensations. |
| Read with | Event Sourcing and CQRS, Idempotency and Exactly-Once Processing, Durable Agent Execution Architecture |
| Use this page when | coordinating multi-service side effects |
Timeline
-
2026-07-01 | Architecture category refresh added this page to the Distributed systems primitives family, linked it to Architecture System Map, and kept it standalone because it owns this boundary: Business transaction split into local steps plus compensations. Source: User request, 2026-07-01
-
2026-06-02 | Page created. Captured why ACID cannot span services, 2PC's blocking problem, choreography vs orchestration, compensation as semantic undo (idempotent/commutative), and implications (no isolation, forward/backward recovery, event-sourcing pairing). Source: Garcia-Molina & Salem, Sagas, 1987