The saga pattern: transactions without a coordinator

Lesson 10's two-phase commit tries to make multiple systems act like one atomic transaction. A saga gives up on that goal entirely and instead breaks the overall operation into a sequence of independent local transactions, each committed on its own system immediately — with a compensating transaction defined for each step, to be run if a later step in the sequence fails.

If "schedule shipping" fails after inventory was reserved and payment was charged, the saga runs compensating transactions for the steps that already succeeded, in reverse order — refund the payment, release the inventory reservation — bringing the overall system back to a consistent state without ever needing a single coordinator holding every participant's locks at once.

Sagas are implemented one of two ways:

A saga is explicitly not atomic in the traditional sense — there's a real window where inventory has been reserved but payment hasn't been charged yet, visible to anything that looks at the system's state during that window. What a saga guarantees instead is eventual consistency (the same term from System Design's CAP lesson): given enough time and no further failures, the system ends up either fully completed or fully compensated back to its starting state — never permanently stuck halfway, which is exactly the blocking failure mode 2PC is vulnerable to.

A compensation isn't simply "undo the write" — it has to account for whatever might have happened since the original step committed. Refunding a payment is straightforward; releasing an inventory reservation is more subtle if that inventory might have already been re-sold to someone else in the meantime. Real saga implementations have to design each compensating step as carefully as the forward step it's undoing, which is the genuine engineering cost of avoiding 2PC's blocking problem.