The Saga pattern is one of those ideas that sounds intimidating until you realize it’s basically a grown-up way of saying: “When a long process has many steps, and one step fails, don’t panic—undo the earlier steps carefully.”
Picture a classic problem in distributed systems. You have multiple services, each with its own database. There is no global transaction anymore. No single “BEGIN … COMMIT” that magically rolls everything back. Reality is messier.
A saga is a sequence of local transactions. Each step does something useful and commits its own data. If a later step fails, the saga runs compensating actions to logically undo the earlier work.
Let’s use a very human example: ordering a product online.
Step 1: Order Service
You place an order. The Order Service creates an order with status “CREATED”.
Step 2: Payment Service
The Payment Service charges your card. Payment succeeds.
Step 3: Inventory Service
The Inventory Service tries to reserve the item. Oops. Stock is gone. This step fails.
Now here’s the key idea. The system does not roll back the database changes automatically. Instead, it reacts.
Compensation steps kick in:
- Payment Service is asked to refund the money.
- Order Service updates the order status to “CANCELLED”.
That whole chain—forward steps plus compensations—is the saga.
You can think of it like this:
“Do A → then B → then C.
If C fails, undo B → then undo A.”
There are two common ways to run a saga.
First, choreography.
Each service listens to events and reacts. Order Service emits “OrderCreated”. Payment Service hears it and charges. Inventory hears “PaymentCompleted” and tries to reserve stock. If inventory fails, it emits “InventoryFailed”, and other services react by refunding and cancelling. No central brain. It’s like a well-rehearsed dance, but debugging can feel like herding cats.
Second, orchestration.
There is a Saga Orchestrator. A central conductor. It tells each service what to do next. “Order Service, create order. Payment Service, charge. Inventory Service, reserve.” If something fails, the orchestrator explicitly tells services to run compensations. This is easier to reason about and debug, at the cost of an extra component.
One subtle but important point: sagas give you eventual consistency, not immediate consistency. For a short time, the system may look “wrong” (payment done, order not yet cancelled), but it will converge to a correct state.
So the Saga pattern is really about being honest with reality. In distributed systems, failures happen. Sagas don’t try to pretend they don’t. They plan for them, clean up after them, and keep the business moving without locking the whole world.
Think of a saga like a story with multiple characters (services). The big question is: who decides what happens next?
In choreography, nobody is in charge.
Each service reacts to events and decides its own next move.
Imagine a group dance at a wedding. No conductor. The music starts, and everyone knows their steps.
Order Service creates an order and emits OrderCreated.
Payment Service hears that event and charges the card, then emits PaymentCompleted.
Inventory Service hears that and tries to reserve stock.
If inventory fails, it emits InventoryFailed, which Payment hears and refunds, and Order hears and cancels.
So the “flow” is spread across services, hidden in event subscriptions.
Strengths:
It’s very decoupled. Services don’t know who comes next. Adding a new participant is easy—just listen to events.
Weaknesses:
Understanding the full business flow can feel like archaeology. Debugging often means replaying events and asking “who reacted to what, and why?” The logic is everywhere.
[ Order Service ] | | OrderCreated v[ Payment Service ] | | PaymentCompleted v[ Inventory Service ] | | InventoryFailed v+------------------+| || Order Service | <-- CancelOrder| |+------------------+ ^ | | RefundPayment[ Payment Service ]What’s happening here:
- Each service listens to events.
- Each service decides what to do next.
- The “flow” exists only in the collective behavior.
- If you ask “who owns the saga?”, the honest answer is: everyone and no one.
Now orchestration.
Here, there is a boss. One component explicitly controls the saga.
Picture an orchestra. The conductor doesn’t play an instrument, but everyone watches them.
The Saga Orchestrator says:
“Order Service, create the order.”
“Payment Service, charge the customer.”
“Inventory Service, reserve stock.”
If inventory fails, the orchestrator says:
“Payment Service, refund.”
“Order Service, cancel.”
All the flow logic lives in one place.
Strengths:
Much easier to reason about. You can read one saga definition and understand the whole business process. Debugging is calmer and more predictable.
Weaknesses:
You introduce a central component. If designed poorly, it can become too powerful or too tightly coupled.
+----------------------+
| Saga Orchestrator |
+----------------------+
| | |
| | |
Create | Charge| Reserve|
Order | Payment| Stock |
| | |
v v v
[ Order ] [ Payment ] [ Inventory ]
Service Service Service
^ ^ ^
| | |
OrderCreated PaymentOK StockFailed
| | |
+--------+--------+
|
Compensation
(Refund + Cancel)
What’s happening here:
- The orchestrator knows the entire process.
- Services are simpler; they just execute commands and report results.
- Compensation is explicit and intentional.
- The saga has a clear “owner”.
A quick mental shortcut that helps in interviews:
Choreography:
“Don’t call us, we’ll react.”
Event-driven, decentralized, flexible, harder to trace.
Orchestration:
“I’ll call you, then you, then you.”
Command-driven, centralized, clearer flow, easier to control.
Neither is “better” in all cases. Simple flows with many independent reactions often fit choreography. Complex business processes with clear steps and compensations often benefit from orchestration.
Distributed systems are messy. These two styles are just different ways of admitting that—and choosing how much coordination you want to see versus infer.
If you squint philosophically:
- Choreography looks elegant and organic, like ants building a nest.
- Orchestration looks deliberate and controlled, like air traffic control.
My Notes 