What Is Saga Pattern?
The saga pattern manages a transaction that spans multiple services or databases by breaking it into a sequence of local transactions. Each step commits independently in its own system; if a later step fails, the saga runs compensating transactions that semantically undo the completed steps, in reverse order. Sagas trade the atomicity and isolation of a single distributed transaction for availability and loose coupling.
Updated
What is the saga pattern?
The term comes from Garcia-Molina and Salem's 1987 paper "Sagas," which addressed long-lived transactions inside a single database: holding locks for minutes or hours strangles concurrency, so a long transaction is split into short ones with compensations. The microservices movement revived the pattern for a different reason — each service owns its own database, and two-phase commit across service boundaries is usually unavailable or operationally unacceptable.
Two coordination styles exist. Choreography has no central coordinator: each service listens for events and emits its own, and the saga emerges from the event chain. Orchestration uses a dedicated coordinator (an orchestrator or state machine) that tells each participant what to do next and tracks progress explicitly.
A well-formed saga also orders its steps around the pivot transaction — the step that cannot be compensated (charging a card, sending an email). Compensatable steps go before the pivot; steps after it must be retryable until they succeed, because there is no going back.
How the saga pattern works
A typical e-commerce order saga spans three services:
- 1.Order service — local transaction: create order in
PENDINGstate. - 2.Inventory service — local transaction: reserve stock for the order.
- 3.Payment service — local transaction: charge the customer.
- 4.On success: order marked
CONFIRMED, reservation converted to a deduction.
If step 3 fails (card declined), the saga compensates in reverse:
- Inventory service: release the stock reservation.
- Order service: mark the order
CANCELLED.
Steps communicate through messages, which can be redelivered, so every step and every compensation must be idempotent. Reliable message hand-off between a step's database write and its outgoing event is itself a hard problem — most implementations pair sagas with the outbox pattern for exactly this reason.
Why the saga pattern matters in real-time systems
Sagas deliberately give up the "I" in ACID. Between the first local commit and the last, the saga's intermediate state is durable and visible: the order exists, the stock is reserved, the payment hasn't settled. Any concurrent reader — another transaction, a fraud check, a pricing engine — can observe this half-finished state and act on it. Known countermeasures (semantic locks such as a PENDING flag, commutative updates, re-reading values before the pivot) reduce but do not eliminate the exposure.
This is why sagas matter beyond correctness of the workflow itself: they multiply the number of moments at which shared state is legitimately in-between. Automated decisions that read across saga participants can see one service's post-step state and another's pre-step state simultaneously — a coherence problem that grows with concurrency, examined more generally in context under concurrency. Designing a saga therefore means designing not just the happy path and compensations, but what every concurrent reader is allowed to conclude from its intermediate states.
FAQ
Related terms
The outbox pattern writes events to an outbox table in the same transaction as the business change, then relays them to a broker, avoiding dual writes.
Event sourcing stores application state as an append-only log of immutable events; current state is derived by replaying them. Covers mechanics and trade-offs.
Idempotency means an operation has the same effect whether applied once or many times. Covers its math origin, HTTP methods, and API idempotency keys.
Eventual consistency is a distributed-systems model guaranteeing all replicas converge to the same value once updates stop. How it works, and its trade-offs.
ACID transactions guarantee atomicity, consistency, isolation, and durability, so a group of database operations either fully succeeds or fully fails.