Microservices Saga Pattern Interview Questions and Answers

Once you split data across services, you lose the single database transaction — and the saga pattern is the standard answer to "then how do you keep things consistent?" It is a favorite interview topic because it forces you to reason about eventual consistency, compensation, and coordination all at once. This page covers the saga questions asked in microservices interviews and the follow-ups that reveal whether you have actually built one.

What is the saga pattern and what problem does it solve?

A saga models a business transaction spanning multiple services as a sequence of local transactions; each service commits its own step and triggers the next, and if a step fails, the saga runs compensating transactions to undo the completed steps. It solves the problem that you cannot wrap a single ACID transaction around several services with separate databases.

The mental shift is from atomic to eventual consistency. There is no moment where everything rolls back instantly; instead the system moves forward step by step and, on failure, walks backward with compensations. The order is never in an impossible state permanently — just temporarily inconsistent until the saga completes or compensates.

Explain choreography vs orchestration.

Choreography: each service subscribes to events and reacts, with no central controller — the flow emerges from services listening to each other. Orchestration: a dedicated orchestrator service tells each participant what to do, in order, and tracks the saga's state.

Choreography is loosely coupled and has no single point of coordination, but the end-to-end flow is implicit — no one place describes "what happens when an order is placed," which makes debugging and change hard as the saga grows. Orchestration centralizes the logic so the flow is explicit and observable, at the cost of a component that must itself be resilient and can become a bottleneck.

Interview note: Follow-up: "which would you pick for a 6-step order saga?" Most engineers pick orchestration for anything beyond a few steps, precisely for the visibility — you can see exactly where a stuck saga is.

What is a compensating transaction, and how is it different from a rollback?

A compensating transaction is a new operation that semantically reverses a completed step — refund a charge, release a reservation — because the original local transaction already committed and cannot be rolled back. A database rollback undoes an uncommitted transaction; compensation undoes the effect of a committed one.

The subtlety interviewers probe: compensation is not always a perfect inverse. If a confirmation email was sent, you cannot un-send it — you send a correction. Designing compensations that are semantically acceptable, not literally reversing, is part of the craft.

Interview note: Trap: "just roll back the other services." You cannot — their transactions are committed. You must issue compensating actions, and some effects (emails, external calls) can only be mitigated, not erased.

Walk through a concrete order saga.

Create order (pending) → reserve inventory → charge payment → confirm order; if payment fails, compensate by releasing the inventory and cancelling the order.

Order Saga (orchestrated):
  1. OrderService.create()        -> ORDER_CREATED (pending)
  2. InventoryService.reserve()   -> INVENTORY_RESERVED
  3. PaymentService.charge()      -> PAYMENT_FAILED  ✗
  -- compensate in reverse --
  2'. InventoryService.release()  -> INVENTORY_RELEASED
  1'. OrderService.cancel()       -> ORDER_CANCELLED

The order stays in a pending state until the saga resolves, and the customer only sees a confirmed order once every step succeeds. Being able to draw this flow, including the compensation path, is often the core of the interview.

Why do sagas replace two-phase commit (2PC)?

2PC holds locks across all participating services for the duration of the transaction and relies on a coordinator that, if it fails mid-commit, can leave everyone blocked — it does not scale and hurts availability. Sagas use short local transactions and compensations, so nothing is locked across services and the system stays available.

The trade-off you are accepting is explicit: 2PC gives immediate consistency at the cost of availability and scale; sagas give availability and scale at the cost of eventual consistency and the complexity of writing compensations. Naming that trade-off is the senior move.

How do sagas handle duplicate messages and retries?

Every step and every compensation must be idempotent, because events are delivered at least once and steps get retried — processing the same event twice must not double-charge or double-reserve. Dedupe by a saga/event ID and record which steps have run.

This is where sagas meet the broader event-driven reality: at-least-once delivery is a given, so idempotency is not optional. A saga that is not idempotent will corrupt state the first time a broker redelivers a message.

What happens if a compensating transaction itself fails?

Retry it with backoff; if it keeps failing, route it to a dead-letter queue and alert an operator, because the saga cannot complete cleanly on its own. Sagas guarantee eventual consistency, and "eventual" sometimes includes human intervention for stuck compensations.

Admitting this is a strength — it shows you know sagas are not magic and that real systems need operational tooling for the tail of failures. Pretending compensation never fails is the naive answer.

How do you keep the saga's state and publish events reliably?

Persist the saga's progress (which steps completed) so it can resume after a crash, and use the transactional outbox pattern to publish events atomically with the local database write. Writing to the database and the broker as two separate steps risks losing or duplicating events if one succeeds and the other fails; the outbox makes them one transaction.

Interview note: Follow-up: "how do you publish an event and commit the DB change atomically?" Write the event to an outbox table in the same transaction, then a relay process ships it to the broker — no dual-write problem.

What interviewers really test

Saga questions test whether you can hold eventual consistency, compensation, and coordination in your head at once. The strongest candidates draw the order saga with its compensation path, choose choreography or orchestration with a reason, and volunteer the hard parts — idempotency, failed compensations, the outbox. Prepare one saga you can narrate forward and backward.

Sagas are the applied case of the topic in the distributed transactions questions, and they run on the mechanics covered in the event-driven architecture question set — pair this page with both. Ground the pattern with the microservices learning path, and practice drawing and defending a saga in a mock interview.