A saga is a way to carry out a long-running business process that spans many steps without holding database locks for the entire duration. The idea is to break the process into a sequence of small local transactions, each of which commits on its own. If a later step fails, the saga runs a series of compensating transactions that explicitly undo the effects of the steps that already committed, rather than relying on a single atomic rollback.
The concept comes from the 1987 paper “Sagas” by Hector Garcia-Molina and Kenneth Salem, published at the ACM SIGMOD conference. They were concerned with long-lived transactions, which under conventional locking would tie up database resources and block other work for unacceptably long periods. Their solution was to relax atomicity: a saga is written as a sequence of transactions that can be interleaved with others, paired with compensating transactions that semantically undo a partially completed saga.
Compensation is what makes a saga different from a classic all-or-nothing transaction. Because each local step has already committed and become visible, there is no automatic rollback to fall back on. Instead the application developer must design an explicit compensating action for each step, such as refunding a charge to undo a payment, so that a failed saga can be walked backward to a consistent state.
The saga pattern became the practical answer to the problem of transactions that cross microservice boundaries, where each service owns its own database and a distributed two-phase commit across all of them is undesirable. In Chris Richardson’s catalog of microservice patterns, a saga is defined as a sequence of local transactions, each publishing an event that triggers the next, with compensating transactions invoked when a step violates a business rule and the work done so far must be undone.