What Is the Saga Pattern in Distributed Transactions?
Learn how the saga pattern coordinates multi-service transactions with compensating actions, and choreography vs orchestration tradeoffs.
Expected Interview Answer
The saga pattern manages a business transaction that spans multiple services by breaking it into a sequence of local transactions, each with a corresponding compensating action, so that if any step fails the saga runs the earlier compensations in reverse instead of relying on a distributed two-phase commit.
Because each microservice owns its own database, a single ACID transaction across services is impractical, so a saga instead executes step one's local transaction and commits it, then triggers step two, and so on; each step is paired with a compensating transaction (like “cancel reservation” for “reserve inventory”) that can undo its effect if a later step fails. There are two common coordination styles: choreography, where each service publishes an event and the next service reacts to it with no central coordinator, and orchestration, where a central saga orchestrator explicitly tells each service what to do and tracks the overall state machine. Choreography scales well for simple sagas but becomes hard to trace as steps grow, while orchestration centralizes visibility and error handling at the cost of a single component that must be highly available. Because compensations run after the fact rather than truly rolling back, sagas provide eventual consistency, not atomicity, so designers must accept that intermediate states are temporarily visible to other parts of the system.
- Avoids distributed two-phase commit across independently owned databases
- Keeps each service autonomous with its own local transaction
- Compensating actions provide a clear, testable failure-recovery path
- Choreography or orchestration can be chosen based on complexity and visibility needs
AI Mentor Explanation
The saga pattern is like a multi-step DRS review process: the on-field umpire's call is a first local decision, then the TV umpire checks ball-tracking as a second step, and if the evidence contradicts the original call, the entire decision is reversed back to the compensating action of overturning it. Each step commits its own local finding before the next step runs, rather than the whole review happening as one indivisible instant. If the final replay step fails to confirm the dismissal, the saga compensates by restoring the batter's not-out status, undoing the earlier steps' implied outcome. The process is a chain of committed steps with a defined undo path, not one atomic decision.
Step-by-Step Explanation
Step 1
Execute the first local transaction
A service commits its own local change and, in choreography, publishes an event, or in orchestration, reports completion to the coordinator.
Step 2
Trigger the next step
The next service in the sequence performs its own local transaction, independent of the first service's database.
Step 3
Detect a failure
If any step fails, the saga stops moving forward and begins invoking compensating transactions for completed steps.
Step 4
Run compensations in reverse
Each prior step's compensating action undoes its effect, bringing the overall business process to a consistent, though not atomic, end state.
What Interviewer Expects
- Understanding why distributed two-phase commit is avoided across microservice databases
- Ability to explain choreography vs orchestration tradeoffs
- Knowledge that sagas provide eventual consistency, not atomicity
- Awareness that every step needs an explicit, idempotent compensating transaction
Common Mistakes
- Assuming a saga rolls back exactly like a database transaction
- Forgetting that compensating transactions must also be idempotent and retried safely
- Choosing choreography for a complex saga and losing overall visibility
- Not accounting for other services observing an intermediate, not-yet-compensated state
Best Answer (HR Friendly)
“When a business process touches several services that each own their own database, we cannot use one big transaction across all of them, so we use a saga: each service commits its own small step, and if a later step fails, we run explicit undo actions for the steps that already succeeded. We choose between having services react to each other's events directly, or a central coordinator that manages the whole sequence, depending on how much visibility and control we need.”
Code Example
saga: place-order
steps:
- name: reserve-inventory
action: inventory-service.reserve
compensation: inventory-service.release
- name: charge-payment
action: payment-service.charge
compensation: payment-service.refund
- name: schedule-shipping
action: shipping-service.schedule
compensation: shipping-service.cancelFollow-up Questions
- How would you make a compensating transaction idempotent?
- What are the tradeoffs of choreography versus orchestration for a five-step saga?
- How do you handle a step that cannot actually be undone, like sending an email?
- How would you monitor and alert on a saga stuck mid-compensation?
MCQ Practice
1. Why is the saga pattern used instead of a two-phase commit across microservices?
Sagas avoid tightly coupling independently owned databases in one distributed transaction, trading atomicity for a sequence of local transactions plus compensations.
2. What is the main difference between saga choreography and orchestration?
In orchestration a central component drives the saga state machine; in choreography, services independently react to events with no central coordinator.
3. What consistency model does the saga pattern provide?
Sagas commit local transactions step by step and use compensations on failure, resulting in eventual consistency rather than true atomic rollback.
Flash Cards
What problem does the saga pattern solve? — Managing a business transaction across services that each own their own database.
What is a compensating transaction? — An action that undoes the effect of a previously committed local transaction.
Choreography vs orchestration? — Choreography: services react to events with no coordinator. Orchestration: a central coordinator drives each step.
What consistency does a saga guarantee? — Eventual consistency, not atomic rollback.