What is the Saga Pattern?
Learn the saga pattern: compensating transactions, choreography vs orchestration, and eventual consistency across services.
Expected Interview Answer
The saga pattern breaks a distributed transaction into a sequence of local transactions, each owned by a different service, where every step has a corresponding compensating action that undoes it if a later step fails, achieving eventual consistency without a blocking two-phase commit coordinator.
Instead of one atomic transaction spanning multiple services, a saga executes step 1 (a local commit in service A), then step 2 (a local commit in service B), and so on; if step N fails, the saga runs compensating transactions in reverse order for every step that already succeeded, such as refunding a payment or releasing reserved inventory. Sagas are coordinated in one of two styles: choreography, where each service publishes events and reacts to events from others with no central coordinator, or orchestration, where a central saga orchestrator explicitly calls each step and triggers compensations. Sagas trade strict ACID atomicity for availability and loose coupling — there is a window where the system is in an intermediate, partially-applied state, so downstream reads must tolerate that or use techniques like semantic locks. This makes sagas the standard pattern for multi-service transactions in microservices architectures, where 2PC’s blocking behavior is unacceptable.
- Avoids the blocking, single-point-of-failure coordinator required by two-phase commit
- Keeps each service autonomous, owning only its own local transaction and database
- Scales well across many independent services without cross-service locks
- Compensating transactions make partial failures explicit and recoverable rather than silently inconsistent
AI Mentor Explanation
The saga pattern is like a multi-stage tour where each leg is booked independently — travel, accommodation, then ground bookings — instead of one giant reservation that must succeed all at once. If the ground booking falls through after travel and hotel are confirmed, the tour manager doesn’t need a single master system to undo everything at once; they simply cancel the hotel and then the travel, one compensating step at a time, in reverse order. Each leg is its own committed local decision, and only a failure triggers this rollback chain. That step-by-step commit-with-compensation approach is exactly what the saga pattern does for distributed transactions.
Step-by-Step Explanation
Step 1
Execute local transaction
The saga runs the next step as a local, committed transaction within a single service.
Step 2
Move to the next step
On success, the saga (via orchestrator or event) triggers the next service's local transaction, and so on.
Step 3
Detect a failure
If any step fails, the saga stops forward progress and begins the compensation sequence.
Step 4
Run compensating transactions
Compensating actions for every already-succeeded step run in reverse order, returning the system to a consistent state.
What Interviewer Expects
- Explains that each step is its own local transaction, not one distributed ACID transaction
- Describes compensating transactions and why they run in reverse order on failure
- Contrasts choreography (event-driven, no coordinator) vs orchestration (central saga coordinator)
- Recognizes sagas provide eventual, not immediate, consistency, and mentions semantic locks or isolation techniques for the intermediate window
Common Mistakes
- Assuming a saga provides the same atomicity guarantees as 2PC
- Forgetting that compensations must be idempotent and handle their own failures
- Not distinguishing choreography from orchestration
- Ignoring the intermediate inconsistent-state window that reads may observe
Best Answer (HR Friendly)
“The saga pattern breaks a big transaction that spans multiple services into a series of smaller local steps, each with its own undo action. If something fails partway through, the system runs those undo actions in reverse to clean up what already happened, so it eventually reaches a consistent state without needing one big service to lock everything at once.”
Code Example
async function placeOrderSaga(order) {
const completed = []
try {
await paymentService.charge(order)
completed.push('payment')
await inventoryService.reserve(order)
completed.push('inventory')
await shippingService.schedule(order)
completed.push('shipping')
return 'saga completed'
} catch (err) {
// run compensations in reverse order
for (const step of completed.reverse()) {
if (step === 'shipping') await shippingService.cancel(order)
if (step === 'inventory') await inventoryService.release(order)
if (step === 'payment') await paymentService.refund(order)
}
throw new Error('saga compensated after failure: ' + err.message)
}
}Follow-up Questions
- What is the difference between choreography-based and orchestration-based sagas?
- How do you keep compensating transactions idempotent when they might be retried?
- How would you handle a read that occurs while a saga is in its intermediate, partially-applied state?
- When would you choose two-phase commit over a saga, if ever?
MCQ Practice
1. What does a saga run when a step in the middle of the sequence fails?
Sagas undo prior successful steps via compensating transactions run in reverse order, restoring the system to a consistent state.
2. What is the key difference between choreography and orchestration sagas?
Choreography is event-driven and decentralized; orchestration uses a central saga orchestrator that explicitly directs each step and any compensations.
3. What consistency guarantee does the saga pattern provide, compared to two-phase commit?
Sagas trade immediate atomicity for eventual consistency and availability, tolerating a window where the system is partially updated.
Flash Cards
What is the saga pattern? — A sequence of local transactions across services, each with a compensating action to undo it on failure.
Choreography vs orchestration? — Choreography: services react to events, no coordinator. Orchestration: a central coordinator directs each step and compensation.
What consistency model do sagas provide? — Eventual consistency, with a visible intermediate partially-applied state.
Why prefer sagas over 2PC in microservices? — Sagas avoid 2PC's blocking coordinator and keep each service's transaction local and autonomous.