In an event-sourced CQRS system, a single business workflow such as placing an order needs to update several independent aggregates -- say Order, Inventory, and Payment -- each with its own consistency boundary. What role does a process manager (saga) play here, and how does it drive the workflow forward?

## The problem it solves A **saga** (or **process manager**, the terms are used near-interchangeably in this context) exists to solve a specific structural problem: Event Sourcing paired with CQRS typically keeps each aggregate small, with one aggregate instance mapping to one event stream and one optimistic-concurrency-checked append per command, so that writes stay fast and uncontended. That design deliberately rules out wrapping a business workflow that spans several aggregates -- reserve inventory, then charge payment, then confirm the order -- inside one ACID database transaction, because each aggregate is its own transaction boundary. The saga pattern, originating from Garcia-Molina and Salem's 1987 paper on long-lived transactions, replaces that single distributed transaction with a sequence of local transactions, each against one aggregate, coordinated by explicit logic that reacts to outcomes and, when something downstream fails, issues compensating actions rather than an automatic rollback. ## How it drives the workflow forward Concretely, a process manager subscribes to the domain events published by the participating aggregates and maintains its own durable state describing where a given workflow instance currently is. - On `OrderPlaced` it issues a `ReserveInventory` command to the Inventory aggregate; - on `InventoryReserved` it issues a `ChargePayment` command to the Payment aggregate; - on `PaymentCharged` it issues `ConfirmOrder` back to Order; - but if it instead observes `PaymentFailed`, it issues a compensating `ReleaseInventory` command and a `CancelOrder` command rather than trying to reverse anything at the database level, because there is no shared transaction to roll back. ## Orchestration versus choreography There are two structurally different ways to implement this. | Style | How it plays out | |---|---| | **Orchestration** | A dedicated process-manager component owns the entire workflow's state machine and is the only thing that issues commands to participants, which makes the workflow's logic and current progress easy to find, test, and monitor in one place, at the cost of that component needing knowledge of every participant and becoming a central piece every workflow change must go through. | | **Choreography** | There is no dedicated coordinator: each aggregate's handler reacts directly to events published by the others, which keeps components decoupled and avoids a central bottleneck, but makes the overall workflow harder to see or reason about as a whole, since the logic is scattered across many independent handlers and typically requires correlation ids and distributed tracing to debug. | ## The trade-off The trade-off, either way, is complexity moved rather than removed: instead of one aggregate boundary and one transaction, the team now owns - **saga state persistence** (the saga's own progress must survive a crash, so it is itself often event-sourced or at least durably checkpointed), - **idempotent command handling** on every participant (so a saga that crashes and resumes doesn't double-issue a command like 'charge payment' a second time), - and **timeout handling** for steps that never acknowledge. Compensations also aren't a true undo: once a payment has actually been captured, the compensating action is a refund, a distinct business operation with its own delay and its own possible failure, not a mirror-image rollback of the original charge. ## Where it shows up A widely referenced real-world shape of this pattern is the classic order/inventory/payment saga described in the microservices literature (for example Chris Richardson's Saga pattern write-ups), and it appears concretely in domains like travel booking, where reserving a flight, a hotel, and a rental car are each independent aggregates or services, and a failure in any one step triggers cancellation compensations in the steps that already succeeded, rather than the system attempting one atomic cross-service transaction across three different providers. ## Timeouts Timeouts deserve their own mention because they're the failure mode teams most often forget until it bites them in production: a saga that issues `ReserveInventory` and waits for `InventoryReserved` has to decide what happens if that event never arrives at all, whether because the message was lost, the Inventory service is down, or it simply takes far longer than expected. Without an explicit timeout, the workflow instance sits stuck indefinitely, invisible until a customer complains their order never confirmed. A robust saga schedules a timer alongside issuing the command, and if the expected response event hasn't arrived by the deadline, treats that exactly like a failure response, triggering the same compensation path, sometimes after a small number of retries with backoff if the failure looks transient rather than permanent. ## Correlation Correlation is the other detail that separates a working saga implementation from a broken one: every command the saga issues and every event it reacts to needs to carry a shared **correlation id**, usually the saga instance's own id, so that when `InventoryReserved` comes back, the saga can find the correct in-flight workflow instance it belongs to, especially when many instances of the same workflow are running concurrently for different orders. Some teams build sagas by hand on top of a message bus with this bookkeeping done explicitly; others use a dedicated orchestration engine, such as **Camunda** or **AWS Step Functions**, that provides durable workflow state, timeout handling, and correlation as built-in features rather than something each team reimplements per saga.