Inside a single database, rolling back a transaction is erasure. The writes vanish, the locks release, the data looks exactly as if you'd never tried. Jim Gray described this in 1981: a transaction transforms state atomically, or it doesn't. Härder and Reuter named the properties ACID in 1983, and for a generation of engineers, "rollback" meant the system handled it.
Then systems outgrew a single machine. Two-phase commit tried to extend the boundary across nodes, but it introduced a blocking problem that turned out to be mathematically inherent — if a participant crashes mid-vote, everyone waits. Garcia-Molina and Salem's 1987 Saga paper proposed the pragmatic fix: break a long transaction into steps that each commit immediately, and if something fails partway through, run compensating transactions in reverse order.
But compensation isn't erasure. It's a new event. The hotel reservation gets canceled, not unbooked. The charge gets refunded, not erased from the ledger. The world saw the intermediate states and kept moving. When modern workflow engines apply sagas across payment rails, third-party APIs, and human approvals, each "rollback" is really a fresh transaction whose business effect is intended to offset the first. Whether it actually does depends on timing, on the external service accepting it, and sometimes on someone picking up the phone.
1981 — Jim Gray at Tandem defines transactions as atomic, consistent, durable. Rollback is total: state reverts as if nothing happened.
1983 — Härder and Reuter add isolation, coin "ACID." The transaction becomes the only unit of recovery.
1987 — Garcia-Molina and Salem publish "Sagas" in ACM SIGMOD. Long transactions decompose into committed steps with compensating counterparts.
2000 — Brewer conjectures the CAP theorem: distributed systems under partition can't guarantee both consistency and availability. Proved by Gilbert and Lynch in 2002.
2007 — Pat Helland argues that large-scale applications already reject distributed transactions in practice. Compensation and messaging are the actual patterns in use.
Today — Temporal, AWS Step Functions, and similar orchestration frameworks formalize sagas for multi-service workflows. Their own docs warn: compensations may fail, may need human intervention, and "need not return data to its original state."