Concepts
Saga pattern / compensating transactions
Intuition
Think of planning a trip: you book the flight, then the hotel, then the car, each booking confirmed separately instead of everything being locked in a single giant transaction that only releases at the end. If the car is sold out, you can't undo time — you cancel the flight and the hotel you had already booked, one by one, as specific "fix-up" actions for each booking. The end result is the same as never having booked anything, but it got there through a path of corrections, not a magical rewind.
How it works
A saga rewrites a long-lived transaction as a sequence of smaller subtransactions, each short enough to commit and release its own locks quickly, and which can be interleaved in time with other transactions in the system. For each subtransaction, a corresponding compensating transaction is defined in advance. If all subtransactions finish successfully, the saga as a whole is considered complete; if one of them fails midway, the system runs the compensations of the subtransactions already completed, in reverse order — what the paper calls backward recovery, undoing the practical effect of the work already committed. A central point: compensating a subtransaction does not mean restoring the database to the exact state before it, but to an acceptable approximation of that state from the application's point of view, since other concurrent transactions may have touched the same data in the meantime. This is exactly the guarantee the saga gives up in exchange: full isolation. Because each subtransaction releases its locks as soon as it finishes, instead of holding everything locked until the whole process ends, other transactions can see and even modify intermediate results of a saga still in progress — something impossible in a traditional ACID transaction. What the saga preserves is a form of observable atomicity: from the outside, the process ends up equivalent to having been fully completed or to never having happened.
In practice
This trade-off — giving up full isolation to avoid holding locks for a long time — is what makes sagas viable both inside a single database and, decades later, as a coordination pattern for business processes that span multiple independent services, each with its own storage, where no central transaction manager can perform a distributed commit. In return, whoever designs the saga takes on the extra responsibility of carefully defining a compensation for each step, one capable of dealing with the fact that the data may have changed since that step ran.
Use it in a design
Practice the cases that rely on this concept in the System Design school.