What Compensation Actually Meant

The problem Héctor García-Molina and Kenneth Salem took on in 1987 was one every database operator already lived with: an operation long enough to touch several systems cannot sit on its locks for the duration. Their paper called the fix a saga. Break the long thing into smaller transactions, let each one commit on its own, release the locks as you go. Which creates the obvious problem. Step four fails, and steps one through three committed minutes ago. Other transactions have read those results and acted on them. There is nothing to roll back to. The data has been seen.

Their answer was the compensating transaction, and the definition is stricter than most of the people who cite it seem to have noticed.

A compensating transaction is a new transaction, moving forward in time, that undoes the semantic effect of the original rather than its physical one. You cancel the reservation. You don't restore the old seat count, because a dozen other reservations committed while you were busy failing and that number is no longer yours to restore. The compensator has to work in the world it lands in, which is never the world the original action left behind.

The paper required that each step's compensating transaction — program name, entry point, parameters — be registered with the system before the forward step was permitted to commit. You could not take step three without having already said how step three gets walked back. That clause tends to drop out of the retelling.

They also knew the compensator could fail: bad code, a missing file, a downstream service that declines the reversal. The saga then sits, unable to finish in either direction, pending until somebody shows up, fixes the compensator and reruns it. The paper's phrase for this is "manual repair by a programmer," which is more honest than most architecture documents manage.

Current workflow engines — Temporal, AWS Step Functions, others — give you real plumbing for this: durable state, retries, a compensation branch to route into when a step fails. What they don't give you is the gate. Nothing stops you shipping a workflow where step three has no way back. Temporal's own example code leaves a step uncompensated on purpose, because an empty account stub is "acceptable." The reason isn't laziness. Compensation is domain logic, and an engine can't know what canceling your reservation means to your business. It routes you to your compensation code. Whether that code exists is your problem.

Agent orchestration frameworks are now adding compensation-shaped primitives, and those are real capabilities. But nothing derives, from the fact that an agent booked a flight, what canceling that flight involves: which window, whose approval, what the traveler gets told. And an agent working across services somebody else runs hits something the paper never had to model. Its compensators ran against systems the saga's owner controlled. An agent's reversal has to be accepted by a counterparty with its own rules about what it will take back, its own clocks and fees, its own residue that reversal doesn't erase. Stripe keeps the processing fee on a refund. PayPal takes $20 for a chargeback whether you win or lose.

The bargain in the paper was simple: you want independent commits and released locks, you say in advance how each one comes back. We kept the flexibility. The other half didn't survive the move to software that takes step three because step three is what's in front of it, and by the time step four fails, one through three are out in the world, committed and already read by somebody else.