Every non-trivial business operation touches more than one system.
An e-commerce order reserves inventory, charges a payment method, and schedules a shipment — three services, three databases. A bank transfer debits one account and credits another across two ledgers that may not even be in the same data center. A cloud VM provisioning workflow reserves a network port, allocates storage, starts the hypervisor, registers billing, and sends a notification — five services, five independent state stores.
The question is: what happens when step four fails after steps one through three have already succeeded?
In a monolith backed by a single database, the answer is simple: roll back the transaction. The database engine guarantees atomicity; either everything commits or nothing does. But when your workflow spans multiple services, each owning its own storage, there is no transaction boundary that wraps them all. There is no rollback button. Step one through three have already made durable changes to systems that do not know about each other, and step four's failure has left the system in an inconsistent state.
This is not a pathological edge case. It is the default condition in any distributed architecture. And it gets worse: the failure might not be a hard error. The network might time out. The billing service might return a 503. You do not know whether step four applied its effect or not — you only know you did not receive a success response. Now what?
This is the problem sagas were designed for.
Client Inventory Svc Payment Svc Shipping Svc
│ │ │ │
1 │──reserve(item)──►│ │ │
│◄──── 200 OK ─────│ │ │
│ [reserved ✓] │ │
│ │ │ │
2 │──────────── charge(card, $99) ────►│ │
│◄───────────────── 200 OK ──────────│ │
│ │ [charged ✓] │
│ │ │ │
3 │─────────────────────── schedule(order) ─────────────►│
│◄─────────────────────────── 503 ──────────────────── │
│ │ │ [no record ✗]
│ │ │ │
╔══════════════════════════════════════════════════════╗
║ ⚠ Inconsistent state ║
║ Inventory: item reserved ✓ (durable) ║
║ Payment: $99 charged ✓ (durable) ║
║ Shipping: no record ✗ (never happened) ║
║ ║
║ Customer paid — nothing ships ║
╚══════════════════════════════════════════════════════╝
Step three failed, but the first two services already committed. Their changes are durable and cannot be undone by simply retrying or ignoring the error. Without an explicit rollback strategy, the system is stuck: inventory is locked, the customer's card was charged, and no shipment was ever created.
Why you cannot use a distributed transaction here
Two-phase commit (2PC) is the classical answer to multi-node consistency. It works: coordinators send PREPARE, wait for all participants to acknowledge, then send COMMIT. But in a microservices architecture it creates a cluster of problems:
Lock contention. Every participant holds locks from PREPARE until the coordinator sends COMMIT or ABORT. Under partial failure or a slow coordinator, those locks hang indefinitely.
Single point of failure. If the coordinator crashes between PREPARE and COMMIT, participants are stuck in an uncertain state with no way to decide unilaterally.
Service coupling. 2PC requires all participants to speak the same protocol. That forces every service — including third-party ones you do not control — to implement a two-phase interface.
For workflows that touch multiple independently deployed services, 2PC is a liability. The saga pattern is the alternative.
The saga pattern in one paragraph
A saga breaks a distributed workflow into a sequence of local transactions, each scoped to a single service. Every step has a compensating action that undoes its effect. If any step fails, the already-completed steps are compensated in reverse order, returning the system to a consistent state. There are no distributed locks, no coordinator protocol, and no coupling beyond the interfaces each service already exposes.
The pattern was described by Garcia-Molina and Salem in 1987 for long-lived database transactions. It maps directly onto modern microservice workflows.
Applied to the order example above:
┌──────────────────────── SAGA ORCHESTRATOR ──────────────────────────┐
│ │
│ ▶ FORWARD (steps execute in order) │
│ │
│ step 1 │ reserve-inventory ──► Inventory Svc ✓ committed │
│ step 2 │ charge-payment ──► Payment Svc ✓ committed │
│ step 3 │ schedule-shipment ──► Shipping Svc ✗ 503 — FAILED │
│ │ │
│ └────────────────────────────────────── ▼ │
│ │
│ ◀ COMPENSATION (triggered automatically, reverse order) │
│ │
│ undo 2 │ refund-payment ──► Payment Svc ✓ undone │
│ undo 1 │ release-inventory ──► Inventory Svc ✓ undone │
│ │ (step 3 never committed — no compensation needed) │
│ │
│ ✓ Every completed step rolled back. Consistent state restored. │
└─────────────────────────────────────────────────────────────────────┘
The key observation: only the steps that actually succeeded need compensation. Step 3 failed before it wrote anything, so there is nothing to undo. The orchestrator tracks this automatically.
Orchestration versus choreography
Sagas are typically implemented in one of two styles:
Choreography — each service publishes events and reacts to events from other services. There is no central coordinator. This scales well but makes the overall workflow hard to trace; understanding what "provisioning" means requires reading every participant.
Orchestration — a dedicated orchestrator drives the saga, calling each service in turn and triggering compensation on failure. The whole workflow is visible in one place, which makes debugging, observability, and retry logic straightforward to reason about.
For provisioning workflows — where the sequence is deterministic, failures are meaningful, and you need an audit trail — orchestration is the right choice.
A Go implementation
Here is a small, dependency-free saga orchestrator in Go. The full source is at — MIT licensed, dependency-free, race-tested.
SOCIAL SHARE CARD GENERATOR