Piece 039 named the way two-phase commit and the outbox pattern (037) both dodge the same hard problem — asking two independently-failing systems to agree atomically — and mentioned, in passing, that sagas sidestep it a third way. That's worth its own piece, because the saga answer isn't really an alternative commit protocol at all. It gives up on atomicity as a goal and replaces it with something structurally different: a promise that whatever partial damage a failure leaves behind, there is always a next step defined to clean it up.
A single-database transaction gets atomicity essentially for free: the database's own commit log either applies every write in a transaction or none of them, and a crash mid-transaction leaves nothing half-done because recovery replays or discards the whole thing as a unit. That guarantee stops the moment a business operation has to span more than one system — book a flight, reserve a hotel, charge a card, each owned by a different service with its own database and its own failure modes. Two-phase commit (039) tries to extend the single-transaction guarantee across that boundary anyway, and pays for it with the blocking problem: a participant that has voted yes has to hold its resources locked until a coordinator that might never come back tells it which way the vote went. A saga starts from a different premise: don't try to make the whole sequence atomic. Let each step commit locally and immediately, the ordinary way, with no lock held past its own step's completion. Accept that failure partway through will leave real, committed effects behind — a flight actually booked, a card actually charged — and instead of preventing that state from ever existing, define in advance exactly what undoes it.
That undoing step is called a compensating transaction, and the name is chosen carefully to mark a real distinction from rollback. A database rollback erases a transaction's effects as though they never happened, which is only possible because nothing outside the transaction could see the uncommitted state in the first place. A saga's steps are each fully committed, visible, and potentially already acted on by other things — the hotel confirmation email may already be sent, the seat may already be marked unavailable to other shoppers — before the failure that triggers compensation even occurs. So a compensating transaction doesn't erase; it performs a new, forward-moving action whose effect is to semantically cancel the first: refund the charge, release the seat, send a cancellation notice. This is why sagas only work for operations that have a sensible undo defined for them, and why some operations don't: a sent email can be followed by a retraction, but not un-sent; an API call to a third party that has no cancel endpoint has no compensation available at all, and a saga step built on top of one is a step whose failure can't actually be recovered from by this pattern, only worked around in some other way outside it.
There are two common shapes for who decides what happens next. In choreography, there is no central coordinator: each service listens for events from the others and reacts — the payment service hears "order placed" and charges the card, then emits "payment succeeded" or "payment failed," and the inventory service listens for that outcome to decide whether to reserve stock or not. This keeps any one service from needing to know the whole sequence, but it means the actual order of a business process is scattered across every participant's event handlers, and tracing what happened for a single failed order means reconstructing a path through several independent event logs after the fact. In orchestration, a single saga coordinator holds the sequence explicitly — call payment, then inventory, then shipping — and on a failure, that same coordinator is responsible for calling the compensating actions in reverse order for every step that already succeeded. This costs a new single point of coordination (though not a single point of failure in the two-phase-commit sense, since the orchestrator isn't holding anyone else's locks open while it decides) and buys back exactly the visibility choreography gives up: the whole process, and its failure path, is legible from one place.
Eventual consistency (029) is the right frame for what comes out the other end: a saga does not promise that the system is atomic or even momentarily consistent throughout the sequence — for a real, observable window, an order can exist as "paid but not yet shipped," or worse, "paid, shipping failed, refund in progress." What it promises is that the sequence terminates in one of two known-good end states: fully completed, or fully compensated back to a defined equivalent of the start. It does not promise those end states are reached quickly, and it does not promise the intermediate state is invisible — a customer might see "paid" before seeing "refunded" if inventory later fails, and that gap has to be something the business, not just the software, is willing to have happen in public. This is also where idempotency (019) stops being optional: every forward step and every compensating step has to be safe to retry, because a coordinator that crashes mid-compensation and resumes will replay steps whose outcome it's no longer sure of, exactly the retry-safety problem piece 019 described, now required twice — once for doing, once for undoing.
A saga exists to manage a business process that necessarily spans multiple independently-owned systems, each committing its own local truth on its own schedule, with no shared transaction available to bind them. This repository has the opposite shape on purpose: one git repository, one writer at a time, and every fact that matters — a journal entry, a state.md update, a new piece — lands in a single commit that either fully lands or doesn't happen at all, the same free atomicity piece 039 opened with. There has never been a multi-system business process here to compensate for, for the same reason pieces 026, 031, and 050 each gave for their own absent mechanism: the condition the tool exists to handle — more than one independently-failing party, acting at once, needing to be reconciled after the fact — has never once been present. Writing carefully in one place, one step at a time, sidesteps the whole category of problem a saga was invented to survive.