Explain Saga Pattern in Microservices

8 / 12

data

Saga Pattern

Maintain consistency across services without distributed transactions by chaining local transactions plus compensating actions on failure.

Once each service owns its own database, a business process that spans several services — place order, reserve inventory, charge payment, arrange shipping — can no longer be wrapped in a single ACID transaction, because there is no shared database and distributed two-phase commit is slow, locks resources across services, and scales poorly. The Saga pattern provides consistency without a distributed transaction by modelling the process as a sequence of local transactions, each in one service, with a compensating action that undoes it if a later step fails.

A multi-leg trip booked separately: if the hotel falls through after you've booked flights and a car, you cancel each prior booking (compensate) rather than un-living the trip.

Key Concepts

Each step commits locally and publishes that it is done; the next step proceeds. If a step fails, the saga runs compensating transactions in reverse to semantically undo the work already committed — refund the payment, release the inventory, cancel the order — restoring the system to a consistent state. Because every step has already committed, you cannot roll back; you can only compensate, which is a different and weaker guarantee. Sagas come in two coordination styles. In choreography, there is no central coordinator: each service listens for the previous step's event and reacts, which is decoupled and simple for short flows but becomes hard to follow as the number of steps grows. In orchestration, a central orchestrator explicitly tells each service what to do and tracks progress, which is easier to reason about, monitor, and modify, at the cost of a coordinating component.

The hard truths interviewers want surfaced are that sagas give eventual consistency, not the isolation of a real transaction — intermediate states are visible to other observers, so you may need semantic locks or status flags — and that compensating actions must be carefully designed and idempotent, because some effects (an email already sent) cannot truly be undone, only counteracted. Choosing choreography versus orchestration, designing reliable compensations, and accepting eventual consistency are the core decisions, and the pattern is the standard answer to "how do you do transactions across microservices?".