Saga

Imagine placing an online order. Behind that one button click, several independent services have to cooperate: one records the order, another charges your card, a third reserves the item from stock, and a fourth schedules the shipment. Each of those services owns its own database. So what happens when the payment succeeds but inventory then reports the item is out of stock? You've taken the customer's money for something you can't deliver, and there's no single "undo" button across four separate systems.

Inside a single database, this is a solved problem: wrap everything in one ACID transaction and the database guarantees it all commits together or not at all. But a business operation that spans place order → charge payment → reserve stock → ship touches four services, each with a separate database, often on different machines.

There is no shared transaction manager that can lock all four databases at once and roll them back as a unit. Holding a global lock across services for the duration of the whole operation would also be disastrous for availability — you'd be freezing inventory and payment systems while you wait on the network. We need a way to keep the operation consistent without a single all-or-nothing transaction.

A saga reframes the operation as a sequence of local transactions, one per service. Each service does its own small piece of work, commits it to its own database, and then triggers the next step. Place the order, then charge the payment, then reserve the stock, then ship — each commit is real and durable on its own.

The trick is the failure path. If a later step fails, the saga walks backward through the steps that already succeeded and runs a compensating transaction for each one: refund the payment, then cancel the order. These compensations don't magically restore the old database state — they're new transactions that semantically undo the effect of the earlier ones. It's a logical rollback, not a true database rollback.

Step through one order below. When Inventory comes back out of stock, predict which steps get undone, and in what order, before you look. Keep an eye on what the customer sees along the way. Then flip to No saga to watch the same failure with nobody to clean it up.

Sagas come in two coordination styles. In choreography, there is no central brain: each service publishes an event when it finishes its local transaction, and the next service listens for that event and reacts. The order service emits OrderPlaced, payment reacts and emits PaymentCharged, inventory reacts to that, and so on. This is naturally pub/sub-driven and pairs well with event sourcing, keeping services loosely coupled — but the overall flow is implicit, smeared across many services and hard to see in one place.

In orchestration, a central coordinator (the orchestrator) owns the workflow. It calls each service in turn, waits for the result, and decides what to do next — including which compensations to fire on failure. The logic lives in one place, which makes the saga far easier to understand, monitor, and modify, at the cost of a component that every step now depends on.

Below, the order saga is paused at the moment it fails. Choose who should drive the compensations and watch it play out, then flip the switch to see the other style at the same step. Notice where the rule "if stock runs out, refund and cancel" ends up living.

Because each step commits independently, a saga gives you eventual consistency, not the instant all-or-nothing consistency of a single ACID transaction. For a window of time the system sits in a partial state — the order exists and the payment is taken, but the stock isn't reserved and the shipment hasn't been arranged yet.

That partial state is also visible to other readers: a saga has no isolation, so the customer can see a charge for an order that's about to be cancelled, and another request can see a half-finished order as if it were final. And because messages get retried and steps can re-run after a crash, every step and every compensation must be idempotent — running it twice must produce the same result as running it once, or you'll double-charge a card or release the same stock twice.

Sagas buy you cross-service consistency, but they aren't free:

• Complexity — you've replaced one transaction with a distributed workflow, plus a mirror-image set of compensation logic and the messaging or coordination plumbing to drive it. That's a lot more moving parts to build, test, and reason about.
• No isolation — intermediate states leak, so every part of the system has to be written with partial progress in mind.
• Designing compensations is hard — for each step you must define a meaningful undo, handle the case where the compensation itself fails (and must be retried), and accept that some real-world effects simply can't be reversed and need human or manual handling instead.

Reach for a saga when a single business operation must span multiple services or databases and you genuinely cannot wrap it in one ACID transaction — the classic microservices situation of distributed data you still need to keep consistent. It's the standard answer for long-running, multi-step workflows like order fulfillment, booking and travel itineraries, or any "do these five things across five teams, and undo them if one fails" process.

If, on the other hand, your operation lives inside a single service and database, don't reach for a saga at all — use a plain local transaction and let ACID do the work. Sagas are the price you pay for distribution, so only pay it when distribution is what forced your hand.