Distributed Transactions & the SAGA Pattern

In the databases module you met ACID transactions: a group of changes inside one database that either all happen or none do. The moment a workflow spans several independent services, each owning its own database (the pattern the microservices module covers in depth), a single transaction can no longer wrap the whole thing. Placing an order might touch an Orders service, a Payments service and an Inventory service, and there is no single database to ask for an all-or-nothing guarantee. This chapter explains the standard answer.

You book a holiday from three separate companies: a flight, a hotel and a car. There is no master button that books all three or none. You book the flight, then the hotel. If the car is unavailable, you do not get to roll back time. Instead you phone the hotel and cancel, then phone the airline and cancel, perhaps losing a cancellation fee. Each booking has its own cancellation that undoes it as well as it can.

• -Each booking is a local transaction: it succeeds or fails inside one company's system.
• -Each cancellation is a compensating action: a new step that semantically reverses an earlier one.
• -The whole sequence, with its cancellations, is a saga.
• -The cancellation fee is a reminder that a compensation is not always a perfect undo.

There is a classic protocol, two-phase commit, in which a coordinator asks every participant to prepare and then, if all agree, tells them to commit. It does give all-or-nothing across databases, but at a price that microservices rarely accept. While participants wait for the coordinator's decision they hold locks, and if the coordinator crashes at the wrong moment they can be stuck holding them. Every service must also be up at the same moment, so the availability of the whole is the product of the availability of every part. Sagas give up the all-or-nothing atomicity in exchange for services that stay independent.

Take the order workflow, with a compensation for each step:

• -Step 1: create the order as pending. Compensation: mark it canceled.
• -Step 2: charge the payment. Compensation: refund it.
• -Step 3: reserve the inventory. Compensation: release the reservation.
• -Step 4: confirm the order.

Now suppose step 3 fails because the item is out of stock. The saga does not roll back, it runs compensations backward through the steps that already succeeded: refund the payment, then cancel the order. The customer ends with no charge and a canceled order, and every service stayed in charge of its own data. The diagram shows exactly that:

• -Orchestration: a central coordinator (the orchestrator) tells each service what to do next and what to compensate on failure. The logic lives in one place and is easy to follow and monitor, but the orchestrator is another component that has to be reliable.
• -Choreography: there is no coordinator. Each service listens for events and reacts: Payments reacts to OrderCreated, Inventory reacts to PaymentTaken. It is loosely coupled, but the overall flow is spread across services, and is hard to see and to debug as it grows.

• -Compensations are not perfect undos. A refund is not the same as the charge never happening, and an email that has been sent cannot be unsent. Design a compensation for each step, and prefer steps that are easy to reverse early on.
• -Every step and every compensation must be safe to repeat, because messages are delivered at least once and a saga step may be retried. This is the idempotency idea from this module.
• -Partial states are visible. Between step 2 and step 4 the customer has been charged but the order is not confirmed. Show clearly that it is pending.
• -Saga progress must be saved, usually in a database, so that a crash in the middle can be resumed or compensated afterwards.

The Wiki card below goes further into distributed transactions and the alternatives: