The Saga Pattern Explained
AdvancedThe saga pattern manages a transaction that spans multiple microservices, each with its own database, where a single ACID transaction is impossible. A saga breaks the operation into a sequence of local transactions; each step publishes an event that triggers the next. If a step fails, the saga runs compensating transactions to undo the previous steps. It trades the strong guarantees of a distributed transaction for availability and eventual consistency.
Think of booking a trip step by step
Booking a holiday means reserving a flight, then a hotel, then a car — each from a different company with its own system. You cannot lock all three at once. So you book them in sequence. If the car rental fails, you do not just abandon the trip in a broken state — you cancel the hotel and the flight (compensating actions) to undo what you already booked. A saga is exactly this: a chain of steps, each with an "undo" if a later step fails.
Step by Step
Key Concepts
Compensating Transaction
An action that semantically undoes a completed step (refund a charge, release a reservation). Sagas rely on these instead of a database rollback, since the steps already committed in separate services.
Choreography
A decentralised saga where each service listens for events and reacts, publishing its own events. No central coordinator — flexible but the overall flow is implicit and harder to follow.
Orchestration
A central orchestrator drives the saga, calling each service in turn and invoking compensations on failure. The flow is explicit and easy to reason about, at the cost of a coordinating component.
Eventual Consistency
A saga does not make all services consistent instantly; the system passes through intermediate states and converges once the saga completes or compensates. Design must tolerate these in-between states.
Key Facts
- Sagas provide atomicity through compensation, not locking — so the system is briefly inconsistent while a saga is in flight.
- Compensating actions must be idempotent and, ideally, always succeed, because you cannot easily compensate a failed compensation.
- Orchestration is usually easier to debug and monitor for complex flows; choreography suits simple, loosely-coupled ones.
Real-World Applications
Placing an order across services
An order saga reserves inventory, charges payment, and creates a shipment across three services. If shipment creation fails, it refunds the payment and releases the inventory — leaving no partially-completed order.
Travel or multi-vendor booking
Booking flight, hotel, and car across separate providers is a natural saga: each is a local commit, and a failure at any step triggers cancellations of the earlier bookings.
Frequently Asked Questions
What is the saga pattern?
It is a way to manage a transaction spanning multiple microservices, each with its own database, where a single ACID transaction is impossible. The operation is split into a sequence of local transactions; each step triggers the next, and if a step fails, the saga runs compensating transactions to undo the earlier steps, restoring consistency.
What is the difference between choreography and orchestration?
In choreography, there is no central coordinator — each service reacts to events from the others and publishes its own, so the flow is decentralised but implicit and harder to trace. In orchestration, a central orchestrator explicitly tells each service what to do and coordinates compensations on failure, making the flow easier to follow at the cost of an extra component.
Why use a saga instead of two-phase commit?
Two-phase commit locks resources across services until all agree to commit, which is slow, reduces availability, and fails badly if the coordinator or a participant crashes. A saga avoids distributed locks by using local transactions plus compensating actions, favouring availability and eventual consistency — a much better fit for microservices.
What is a compensating transaction?
It is an action that semantically undoes a previously completed saga step — for example, refunding a payment that was charged or releasing inventory that was reserved. Because each step already committed in its own service database, you cannot roll them back; instead you compensate to bring the system back to a consistent state.