An order-placement flow in a CQRS/event-driven system needs to reserve inventory, charge payment, and update a read-model 'order status' projection, each owned by a different service with its own write model. No single ACID transaction spans all three. What coordination pattern keeps this consistent, and what happens if the payment step fails after inventory has already been reserved?

## What a saga is A **saga** decomposes a business transaction that spans multiple services or modules into a sequence of local transactions, each of which commits independently within its own owning service, plus a **compensating transaction** defined for every step that has a real, externally-visible effect. In this order-placement example, the sequence is: 1. `reserve-inventory` 2. `charge-payment` 3. and finally a projection update to the order-status read model Someone — either a central process manager (**orchestration**) or the participating services reacting to each other's published events (**choreography**) — has to track which steps have completed and drive the flow forward or backward. ## Orchestration against choreography | Style | How it drives the flow | Where it fits | |---|---|---| | Orchestration | explicitly models the saga as a state machine: a durable process manager holds the current step, issues the next command, and on failure looks up and issues the compensations for whatever already succeeded | tends to win for anything with branching logic, timeouts, or more than two or three steps, because it gives one place to see and debug the flow | | Choreography | instead has each service publish a domain event when it finishes its step, and the next service in line subscribes and reacts, with no single component holding the overall picture | stays simpler for very short chains but gets hard to reason about as steps multiply, since no one component owns the 'is this saga stuck?' question | ## Why the pattern exists This pattern exists because cross-service ACID transactions — classically implemented via **two-phase commit** — don't work well at the scale and topology CQRS and microservices operate at. - Two-phase commit requires every participant to hold locks and stay available until a coordinator finalizes the outcome, which is fundamentally at odds with independently-deployed services, asynchronous messaging, and horizontal scaling; a coordinator outage or a slow participant blocks everyone. - Business processes, however, still need multi-step consistency — an order genuinely shouldn't end up charged with no inventory reserved, or reserved with no charge — so sagas provide a way to get eventual business-level consistency across boundaries that will never share a real transaction. ## The trade-off The trade-off is that a saga gives up true atomicity for availability and loose coupling. - **Intermediate states become visible to the outside world** during the flow — inventory is decremented against available stock while payment is still pending, which a naive read of 'stock remaining' could observe. - **Compensations are not database rollbacks;** they are business logic that must be explicitly designed as the semantic opposite of the original step, and they can have residual effects of their own (releasing a hotel hold might trigger a notification email that can't be un-sent, for instance). - **Building and maintaining a saga's state machine and its compensations is real, ongoing engineering work** per business flow, not something that comes for free from choosing CQRS. ## Failure modes Several failure modes are specific to sagas. - **A compensation can itself fail** — releasing inventory might hit a transient error — which typically needs its own retry policy and, ultimately, a dead-letter queue plus manual intervention if retries are exhausted. - **An orchestrator process crashing mid-flow** needs durable, persisted saga state (not just in-memory) so it can resume from the last recorded step on restart, and every step handler needs to be idempotent so a resumed or retried step doesn't double-charge or double-reserve. - **Choreography is additionally vulnerable to ordering issues** — events processed out of sequence can leave participants in an inconsistent view of where the saga actually is — which is usually mitigated with correlation ids and explicit step sequencing. - **The 'dual write' problem** is a subtler, very common bug: a step commits its local database change but then fails to publish the event that should trigger the next step, silently stalling the saga; the standard fix is a **transactional outbox**, writing the event to an outbox table in the same local transaction as the state change, then reliably publishing from that outbox afterward. ## Where the pattern comes from This is a well-documented, named pattern — Chris Richardson's microservices.io catalog describes it under exactly this order-processing example (reserve inventory, charge card, ship), and the underlying idea traces back to the 'process manager' pattern in Hohpe and Woolf's Enterprise Integration Patterns. In practice, teams implement the orchestration style using durable workflow engines such as Temporal, AWS Step Functions, or Camunda, specifically because they provide the durable-state, retry, and idempotency machinery a hand-rolled saga orchestrator would otherwise need to reinvent.