The Saga Pattern

A single-database transaction guarantees all-or-nothing across multiple writes - but that guarantee doesn't extend across service boundaries, where each service owns its own data store. A saga is the pattern for achieving an equivalent "all succeed, or everything is undone" outcome across a multi-service workflow, without a distributed transaction spanning every service.

Placing an order might involve: charging a payment, reserving inventory, and scheduling a shipment - three separate services, each with its own database. If inventory reservation fails after payment already succeeded, something needs to undo the payment; a plain database transaction can't span all three services to make that automatic.

A saga is a sequence of local transactions, each scoped to one service's own database (so each individual step IS a normal, safe, all-or-nothing transaction), with a compensating action defined for each step that can undo its effect if a later step in the sequence fails. Note that a compensating action isn't always a perfect literal reversal - "cancel a shipment" that already left the warehouse might mean "intercept and return" rather than undoing something that hasn't happened yet, which is a real design nuance sagas have to account for.

In orchestration, a dedicated saga coordinator service explicitly calls each step in sequence and explicitly triggers compensating actions on failure - the workflow logic lives in one visible place, which makes the overall sequence easy to understand and modify, at the cost of that coordinator becoming a service every other service in the saga now depends on.

In choreography, there is no central coordinator - each service publishes an event when its own step completes, and the next service in the sequence subscribes to that event and reacts by performing its own step, publishing its own completion event in turn. This avoids the single coordinator dependency, but the overall workflow logic becomes implicit, scattered across every service's event subscriptions - understanding "what happens when an order is placed" means tracing a chain of event subscriptions across many services instead of reading one coordinator's code.