About this demo
A saga is a sequence of local transactions, each in a separate service, that together complete a distributed business transaction. Unlike a two-phase commit, no global lock is held across services — instead, each step publishes an event that triggers the next. This makes sagas resilient to partial failures: if any step fails, previously completed steps are undone by compensating transactions that execute in reverse order.
The four steps here model a real e-commerce order saga: create the order, reserve inventory, charge the customer, and send the confirmation. Injecting failure at Payment means the inventory reservation must be released and the order cancelled in reverse. Compensating transactions must be idempotent and eventually consistent — they cannot always undo an action atomically, which is why saga design requires careful thought about what compensation actually means for each step.