Papers
Sagas
Hector Garcia-Molina, Kenneth Salem · ACM SIGMOD International Conference on Management of Data (SIGMOD) 1987, 1987
The problem: long transactions locking database resources
The paper's starting point is what the authors call long-lived transactions (LLTs): operations that need to hold locks on database rows or tables for a relatively long period to preserve the classic properties of a transaction. The problem is that, while these long transactions hold their locks, short and far more common transactions in the same system are blocked waiting, which degrades the overall performance of the database. The authors observe something seemingly obvious but with important consequences: a sequence of short transactions is not, by itself, an atomic transaction. Each of these individual transactions commits and releases its own locks as soon as it finishes, so there is no traditional concurrency control (such as two-phase locking) that treats the whole sequence as a single indivisible unit without going back to holding resources the whole time — which cancels out the advantage of splitting the work into smaller pieces. The practical motivation behind this is business processes that naturally span several distinct steps, each touching different parts of the database, and that fit neither the model of one giant blocking transaction nor the opposite extreme of simply having no guarantee at all about the final outcome of the process as a whole.
The core idea: a saga as a sequence of subtransactions with compensation
The paper's central proposal is the saga: a long transaction rewritten as a sequence of smaller subtransactions, each short enough to commit independently and release its locks quickly, and which can be interleaved in time with operations of other transactions in the system. For each subtransaction of the saga, a corresponding compensating transaction is defined in advance. The system guarantees that either all the subtransactions of the saga complete successfully or, if one of them fails midway, the compensating transactions of the already completed subtransactions are executed in reverse order, undoing the practical effect of the work already committed (the paper calls this backward recovery, in contrast with forward recovery, which tries to keep going until the saga completes). A subtle point highlighted by the authors is that compensating a subtransaction does not necessarily mean returning the database to the exact state that existed before it ran — it means restoring an acceptable approximation of that state, sufficient from the application's point of view, since other transactions may have changed the same data in the meantime. This flexibility is what makes sagas implementable even on database systems that offer no native support for the concept.
The central trade-off: atomicity without full isolation
The paper makes explicit a trade-off that distinguishes a saga from a traditional transaction: by allowing each subtransaction to commit and release its locks as soon as it finishes, instead of holding everything locked until the end of the whole process, a saga gives up the full isolation that a conventional ACID transaction offers. This means that, while a saga is running, other concurrent transactions can see and even modify data that has already been changed by the saga's intermediate subtransactions, something that would not happen if the entire saga were protected by locks from start to finish. In exchange for this concession, the saga still delivers a form of atomicity: the process as a whole ends in an observable way equivalent to having been fully completed or never having happened, thanks to the compensation mechanism. This trade shifts part of the responsibility onto whoever designs the saga: each subtransaction must have a carefully defined corresponding compensation, able to cope with the fact that the data may have been touched by other transactions in the meantime, and the paper discusses how this control can be maintained even in existing systems that have no built-in support for the saga concept, requiring this registration of compensations at the application layer.
Legacy: the saga pattern in distributed architectures and microservices
Although the 1987 paper was written with transactions inside a single database system in mind, the same core idea — breaking a long process into smaller steps, each with an associated compensating action, instead of trying to hold a blocking distributed transaction from start to finish — reappears decades later as the basis of what is now widely called the "saga pattern" in microservices architectures. In this more modern context, the "steps" stop being subtransactions of a single database and become calls to independent services, each with its own storage; since there is no longer a single transaction manager able to coordinate a distributed commit across all these services, the per-step compensation logic becomes the explicit responsibility of whoever designs the business flow, following approaches such as orchestration (a central coordinator triggers each step and, if needed, the compensations) or choreography (each service reacts to events from the previous ones). What is preserved, in spirit, is exactly the paper's original guarantee: the process as a whole observably ends up either fully completed or fully undone, even without full isolation while it runs — the same trade-off discussed in the original paper, now applied to distributed systems that do not share a single database.
See the ideas at work
Practice the designs that use this paper in the System Design school.