The Runtime Theory

Saga Compensation Flow: Local Transactions, Events, and Reverse Rollback

Trace a saga through sequential local transactions, a mid-flight failure, and compensating transactions running in reverse order to restore a consistent state.

The Runtime Theory Team08 stages

trace / request.md

SAGA BEGINSRESERVEFUNDS COMMITSHOLD INVENTORYCOMMITSFORWARD PROGRESSA STEP FAILSCOMPENSATEIN REVERSEALL COMPENSATIONSDONECONSISTENTBUSINESS STATE

readyThe saga orchestrator starts a business workflow spanning multiple services. No distributed lock, no shared transaction — each step is an independent local transaction.

A saga trades atomicity for availability. Instead of holding locks across services — which is what 2PC does and why it blocks — each step commits immediately and records how to undo itself. The undo is a compensation: a new transaction that reverses the effect of the old one, like a refund for a charge.

The ordering is the entire contract: compensations run in reverse order of the steps that succeeded. Step 3 failing means step 2's hold is released before step 1's charge is refunded, because dependencies flow forward and undos must flow backward. Every compensation is idempotent and retryable — the orchestrator can crash mid-compensation and resume without double-releasing anything. The machine never pretends nothing happened: intermediate states are real, committed, and briefly visible. The saga's guarantee is only that the end state is consistent — which is why it suits business workflows over data replicas, where temporary inconsistency is an acceptable price for never blocking.