The Saga Pattern — Orchestration, Choreography & Rollback

Run a multi-step Order saga across services that share no database: Reserve Inventory → Charge Payment → Arrange Shipping → Confirm. Coordinate it with a central orchestrator or with pure choreography — then fail a step and watch compensating transactions roll the whole thing back in reverse.

A real multi-step transaction across services that share no database. Pick where it fails, choose how it's coordinated, and run it — then watch the rollback. This is the pattern behind every checkout, booking, and money transfer at scale.

Inject a failure at:

🧭

Saga Orchestrator

issues commands ↓ · listens for events ↑

📦

Inventory

idle

💳

Payment

idle

🚚

Shipping

idle

✅

Confirm

idle

The orchestrator drives each step and, on failure, commands the reverse.

Command & event log

// run the saga to see the flow

Try failing at Shipping: Inventory and Payment already committed, so the saga refunds the payment and releases the inventory — in reverse — leaving no half-finished order. Then switch orchestration↔choreography and watch who drives it.

What just happened

▹A business transaction that spans services can't use one database transaction — there's no shared DB to roll back. The Saga pattern runs it as a sequence of local steps, each emitting an event, with a compensating action that undoes it.
▹Orchestration uses a central saga coordinator that issues commands and decides the next step (easy to see and reason about). Choreography has each service react to the previous event with no coordinator (decoupled, but the flow is implicit).
▹The hard, beautiful part is failure: when a step fails, the saga runs compensating transactions in REVERSE over everything already done — refund the payment, release the inventory — until the system is consistent again. That's how real distributed systems stay correct without distributed locks.