Saga Pattern
Also known as: saga, distributed transaction pattern
A saga replaces a distributed ACID transaction with a sequence of local transactions, each publishing an event that triggers the next. If a step fails, previously completed steps are undone by explicit compensating transactions. The overall workflow is eventually consistent, never atomic, and intermediate states are visible.
Last reviewed · Part of the Architecture Glossary
In practice
An order saga: reserve inventory → charge payment → create shipment. Payment fails, so the compensation runs: release inventory. Two ways to wire it:
- Choreography — each service listens for the previous service's event. No coordinator, but the workflow exists only as an emergent property of the subscriptions, and nobody can point at where it is written down. Fine at three steps, unmaintainable at eight.
- Orchestration — a saga coordinator holds the state machine and issues commands. One place to read the flow, one place to query "where is order 4471 stuck," at the cost of a component that must itself be durable.
Compensations are the hard part, because they are semantic, not mechanical. You cannot roll back a sent email; you send an apology. You cannot unship a package; you issue a return label. Writing the compensations first is a good test of whether the decomposition was right at all.
When it matters
A business process spanning services that own separate databases, where two-phase commit is unavailable or unacceptable.
Common mistake
Reaching for a saga to paper over bad bounded contexts. If three services must always change together, the saga is compensating for a boundary drawn in the wrong place — merging them is cheaper than orchestrating them.
See also
- Transactional OutboxThe transactional outbox pattern writes an outgoing message into an `outbox` table inside the same database transaction as the state change it describes.
- Eventual ConsistencyEventual consistency guarantees only that if writes stop, all replicas eventually converge to the same value.
- Bounded ContextA bounded context is an explicit boundary within which a domain model and its terms have one consistent meaning.