Book a trip online and one click quietly kicks off a small chain of events: charge your card, reserve the hotel, hold the flight seat, book the rental car, email your confirmation. Each of those lives in a different system, run by a different company, with its own database. Now imagine the flight booking fails on step four — after your card was already charged and the hotel was already reserved. What undoes the parts that already happened? Nobody wants a charged card and half a vacation.
That problem — a single business action spread across many independent steps, where any step can fail — is exactly what the saga pattern was built to solve. It’s one of the most important ideas in modern software, and once you see it, you’ll notice it behind almost every “place order,” “book,” or “sign up” button you press. This is a plain-English guide to what a saga is, how it recovers from failure, and the two very different ways software runs one.
📖 What a saga actually is
For decades, the gold standard for “all or nothing” was the database transaction: wrap several changes in a single BEGIN … COMMIT, and either every change sticks or none do. It’s clean and automatic. But it only works when everything lives in one database that you control. The moment your operation reaches across separate systems — your payment processor, an airline, a warehouse, a shipping partner — there is no shared “commit” button to wrap around all of them.
A saga is the answer. Instead of one giant all-or-nothing transaction, a saga is a sequence of smaller steps, each of which finishes on its own — and each step comes paired with an undo step, called a compensation. If everything succeeds, great: the saga is done. If a step partway through fails, the saga runs the undo steps for everything that already happened, in reverse, so the end result is as if the whole thing never ran.
That’s the key promise, and it has a name: semantic atomicity, or more memorably, “all-or-compensated.” The business outcome is all-or-nothing, even though there was never a single transaction holding it together.
The name itself is a good hint. A saga is an old Norse word for a story — a tale told in ordered chapters, sometimes with a twist, a failure, and an apology near the end. A distributed business operation really is a little story: chapter one charges the card, chapter two reserves the room, and if chapter four goes wrong, the earlier chapters get their own closing scenes that walk the story back.
🔄 Compensation is not a rewind
Here’s the part that trips people up, and it’s worth slowing down for. A compensation is not a time machine that restores the exact state of the world before the step ran. It’s a new forward action that cancels out the old one’s effect.
Think about a refund. If a saga charged your card and then needs to undo it, it doesn’t reach back in time and un-charge you. It issues a refund — a brand-new transaction. Your bank statement now shows two line items: the charge and the refund. The net effect is “you paid nothing,” but the history is different from “never charged.” That’s semantic atomicity in a nutshell: the outcome is undone, not the timeline.
This distinction matters enormously, because some actions genuinely cannot be undone. You can’t un-send an email. You can’t un-ship a package that’s already on a truck. The best you can do is a new compensating action: send a correction email, or start a return. Good saga design takes this seriously — which leads directly to the single most important design rule, coming up in a moment.
Because these undo steps run across a shaky network where messages can arrive twice or out of order, compensations also have to be idempotent — a fancy word for “running it twice does no more harm than running it once.” A “cancel booking” message that arrives twice must not somehow un-cancel and re-charge. If you remember one piece of jargon from this article, make it idempotent; it’s the quiet discipline that keeps distributed systems from double-charging people.
🎭 Two ways to run a saga: conductor vs. jazz band
Every saga has to coordinate its steps somehow, and there are two classic styles. The difference is simply where the coordination lives.
Choreography is like a jazz ensemble with no conductor. Each service listens for events and reacts: the order service announces “order placed,” the payment service hears that and charges the card, then announces “payment done,” which the warehouse service hears and reserves stock. The overall dance emerges from everyone reacting to everyone else. There’s no single boss, which keeps things loosely coupled and resilient — but for anything complex, the actual business process exists nowhere in particular. It’s scattered across a dozen services, and reconstructing “what actually happens when someone orders” means piecing together logs like a detective.
Orchestration is like an orchestra with a conductor. One central coordinator — an orchestrator — explicitly calls each step in order, waits for the result, and decides what’s next, including which undo steps to run on failure. The whole process lives in one readable place, which makes it far easier to understand, debug, and change. The cost is that you now run and maintain that coordinator, and you have to keep its business logic honest so it doesn’t secretly swallow work that belongs in the individual services.
For simple, high-volume flows of three or four steps, choreography’s looseness shines. For anything complex, stateful, or business-critical, most seasoned teams reach for orchestration — the explicit conductor is usually easier to live with than an invisible one. (If that “central coordinator directing specialists” picture sounds familiar, it’s the same shape as the orchestrator-worker pattern used to coordinate AI agents.)
🛑 The point of no return
The most elegant idea in saga design is the pivot — the point of no return. Some steps are easily undoable (release a held seat, refund a charge). Some are genuinely irreversible (send the email, ship the goods). A well-designed saga is deliberately ordered so that all the reversible steps happen first, followed by a single go/no-go moment, after which everything is irreversible but guaranteed to finish.
Picture an online order arranged as: reserve inventory (undoable) → authorize payment (the pivot — the go/no-go) → ship the package and send the confirmation email (irreversible, so they come last). If anything fails before payment, the saga cleanly backs out — release the inventory, cancel the order, no harm done. Once payment succeeds, the saga is committed to going forward: it will retry shipping and email until they succeed, because there’s no sane way to “un-ship.” The pivot is the frontier: before it, you can always go back; after it, you only go forward.
This is why the “compensation is not a rewind” point matters so much in practice. You design around the actions you can’t undo by pushing them past the pivot, so they only ever run when the whole story is guaranteed to reach its happy ending.
🤖 Why AI agents are bringing sagas back
Sagas were invented for databases in 1987 and adopted by web-scale companies for microservices in the 2010s. Now they’re having a third moment — with AI. A multi-step AI agent that books travel, files expenses, or edits your files is running a distributed operation with the exact same failure question: if the agent completed four of six actions and step five fails, what undoes the first four?
Today’s autonomous-agent excitement mostly skips this. But an agent that takes real actions in the world needs the same discipline a saga demands: a registered “undo” for each action it can reverse, tolerance for retried steps that shouldn’t double-fire, and a hard rule that truly irreversible actions — moving money, sending a message, deleting a file — sit after a human or automated go/no-go check. The saga pattern is, quietly, a blueprint for making AI agents safe to let loose. It pairs naturally with the modeling discipline in domain-driven design for AI agents and the boundary-guarding of an anti-corruption layer.
🧰 When you actually need one
A saga is powerful, but it’s also more work than a single database transaction, and it comes with a real cost: while a saga is mid-flight, other parts of the system can briefly see the in-between state (the order exists but isn’t paid yet). Experienced engineers treat that as a warning sign, not a default. The best distributed transaction is no distributed transaction.
So the honest rule is: reach for a saga only when a business operation genuinely must span multiple independent systems, and everyone involved accepts that a brief, visible “half-done” state is okay because the system will converge. If you can redraw your boundaries so the whole operation fits inside one system with one real database transaction, do that instead — it’s simpler and safer. The saga is the tool for when the crossing is truly unavoidable, which, in a world of microservices and third-party APIs, is more often than anyone would like.
❓ Frequently Asked Questions
What is the saga pattern in simple terms? It’s a way to run a multi-step operation that spans several independent systems so that it ends either fully done or fully undone. Instead of one big all-or-nothing database transaction, a saga runs each step separately and pairs each step with an “undo” step (a compensation). If a later step fails, the earlier steps’ undos run in reverse, so the net result is as if nothing happened.
What is a compensating transaction? It’s the “undo” for a saga step — but it’s a new forward action, not a rewind. To undo a charge, a saga issues a refund; to undo a booking, it issues a cancellation. The effect is reversed, even though the history still shows both events.
What’s the difference between orchestration and choreography? Both coordinate the same steps; they differ in where the control lives. In choreography, each service reacts to events with no central coordinator (like a jazz band). In orchestration, one central coordinator explicitly drives every step (like a conductor). Orchestration is usually easier to understand and debug for complex flows.
Is a saga the same as a database transaction? No. A database transaction gives true all-or-nothing (atomicity and isolation) inside one database, automatically. A saga gives all-or-compensated across many systems, and it deliberately gives up isolation — meaning other parts of the system can briefly see the half-finished state while the saga is running.
When should I use the saga pattern? Only when an operation must span multiple independent systems and a brief, visible intermediate state is acceptable. If you can keep the whole operation inside a single database with one transaction, that’s simpler and safer — prefer it whenever you can.
📚 Further Reading
- What Is Domain-Driven Design? — how to draw the system boundaries a saga crosses
- The Orchestrator-Worker Pattern — the conductor model, applied to AI agents
- Anti-Corruption Layers — guarding the boundary between systems that don’t trust each other
- Domain-Driven Design for AI Coding Agents — why these old patterns fit autonomous agents so well
📚 Recommended Resources
Disclosure: some links below are Amazon affiliate links. If you buy through them, I earn a small commission — at no extra cost to you — which helps keep this site running.
Sagas sit at the crossroads of microservices, messaging, and reliability engineering. These five books are where the pattern and its supporting ideas are explained best.
- Microservices Patterns — Chris Richardson · Book. The modern home of the saga pattern — orchestration vs choreography, the pivot transaction, and the outbox — with worked examples.
- Enterprise Integration Patterns — Gregor Hohpe & Bobby Woolf · Book. The classic catalog of messaging patterns, including the Process Manager that most “sagas” in real frameworks actually are.
- Designing Data-Intensive Applications — Martin Kleppmann · Book. The theory beneath it all — transactions, consistency, and why distributed all-or-nothing is so hard.
- Release It! (2nd ed.) — Michael Nygard · Book. Stability and resilience patterns for systems that talk to other systems that fail — the operational half of a good saga.
- Understanding Distributed Systems — Roberto Vitillo · Book. An approachable on-ramp to the whole landscape — replication, consistency, and coordination — if the others feel like a leap.