What is the Saga Pattern?

Learn the saga pattern: compensating transactions, choreography vs orchestration, and eventual consistency across services.

mediumQ109 of 224 in System Design Est. time: 5 minsLast updated: July 2026

Open Code Lab

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

Orchestrated saga for order placement

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?

2. What is the key difference between choreography and orchestration sagas?

3. What consistency guarantee does the saga pattern provide, compared to two-phase commit?

Flash Cards

1 / 4

What is the Saga Pattern?

Expected Interview Answer

AI Mentor Explanation

Step-by-Step Explanation

Execute local transaction

Move to the next step

Detect a failure

Run compensating transactions