A Refund Is Not a Rollback

A database rollback works because the engine controls the entire timeline. Nothing was visible outside the transaction (isolation), the undo information is in the same log as the redo information (atomicity), and no external party ever observed the intermediate state. The engine can therefore restore the pre-transaction state and honestly claim nothing happened, because from every legal observer’s point of view, nothing did.

None of those three conditions holds across services. The intermediate state *was* visible — that is the defining property of a saga. The undo information lives in a different system from the redo. And an external party — the customer, the card network, a downstream consumer — may already have observed and acted on it.

So the compensating action cannot be an undo. It is a new local transaction, executed later, that produces a *new* effect intended to counteract the first. charge(100) compensated by refund(100) leaves a balance of zero and a ledger with two rows. That ledger is not a bug to be hidden; in most regulated domains it is legally required. The system state converges; the history does not.

This is the consequence teams discover late. A compensating action is a remote call. It can time out with an unknown outcome. It can be retried and applied twice. It can be delivered out of order. It can fail permanently because the compensating service is down, or because the operation is no longer legal — the refund window closed, the account was frozen, the coupon expired.

So every compensation needs the full apparatus that every other step needs: its own idempotency key, its own retry policy with backoff, its own dead-letter path, its own monitoring. A team that carefully makes forward steps idempotent and then writes await paymentService.refund(orderId) in the catch block has built a saga whose recovery path is less reliable than its happy path — which is precisely backwards, because the recovery path runs exactly when things are already going wrong.

And a failed compensation is worse than a failed step, because the saga can now go neither forward nor backward. A failed forward step has an obvious response: compensate. A failed compensation has no protocol-level response at all. It is the saga’s equivalent of 2PC’s blocking window, except that no coordinator recovery will resolve it — only a human, or a business decision to accept the loss.

The naive compensation restores a remembered value: "before my step, the address was X, so set it back to X." Between the step and the compensation, another saga legitimately changed the address to Y. Your compensation now silently destroys Y. This is a lost update, and it is the single most common compensation bug.

The fix is to make effects and compensations relative and commutative wherever possible. balance -= 50 compensated by balance += 50 is correct no matter what else happened in between, and no matter what order the operations land in. stock_reserved += 1 compensated by stock_reserved -= 1 likewise. Absolute assignment is only safe when guarded by a version check that fails loudly rather than overwriting (Two Writes, No Order, One Answer Required and Version Vectors: Making the Conflict Visible are the same reasoning in a replication setting).

The second ordering hazard is stranger and catches people out: a compensation can arrive before the thing it compensates. The driver times out on step 2, decides to compensate, and issues the refund — while step 2’s original charge is still in flight and commits afterwards. The compensating service is asked to reverse something that has not happened yet. This is not hypothetical; it is the ordinary consequence of A Timeout Tells You Nothing About Whether It Happened plus retries.

Therefore a compensation must be tolerant of a missing original. "Cancel reservation R" where R does not exist must be a durable, recorded no-op that also poisons R so that a late-arriving create is rejected — not a 404 that the driver treats as a failure and not a silent success that lets the zombie original commit. The compensating service needs a tombstone, not an error.

Some effects have no counteraction, and no amount of engineering creates one. An email that was delivered has been read. A push notification appeared on a lock screen. A pallet left the warehouse on a truck. A tweet was seen and screenshotted. Data was disclosed to a third party. A trade was executed on an exchange. A physical door was unlocked.

For these there is no compensation, only a *follow-up*: a correction email, a recall request, a return label, an apology credit. These are new business actions with their own cost and their own failure rate, and — critically — they do not restore the invariant. They negotiate a different acceptable state. "We sent you an order confirmation in error" is not the same outcome as never having sent it, and pretending otherwise in a design document is how teams end up promising customers something the system cannot deliver.

The design rule that follows is the most actionable idea in this module: order the saga so that non-compensable effects happen last. Every step before them can be undone if a later step fails; once you cross into the irreversible region, the only legal direction is forward.

Classify every step in a saga into one of three kinds. Compensatable: it has a real compensation and can be undone semantically. Pivot: the point of no return — the step after which the saga must complete. Retriable: it comes after the pivot, it is guaranteed to eventually succeed given enough retries, and it is never compensated.

The pivot is often the irreversible step itself, or the last step that can still fail for business reasons. Once you order the saga as *compensatable steps → pivot → retriable steps*, two useful properties fall out. Before the pivot, any failure unwinds cleanly. After the pivot, there is nothing to unwind, so the only obligation is to keep retrying until every remaining step succeeds — which means those steps must not be able to fail for business reasons at all, only for transient ones.

This classification is a design constraint, not a description. If your "retriable" step can return "insufficient funds", it is not retriable and the saga is mis-ordered. Fixing that usually means moving a check earlier — validate before the pivot, act after — which is exactly why the classification is worth doing on paper before writing code.

Because compensation is visible, part of the design is not technical. If a charge and a refund will both appear on a statement, someone must decide whether the customer is told, and what the wording is. If a confirmation email will be followed by a cancellation email, product must own that pair. If a reservation lapses, the UI must not have promised it was guaranteed.

This is the sense in which "compensation is not rollback" is a product statement as much as an engineering one. A rollback needs no communication because nobody saw anything. A compensation always has an audience, and designing the saga without designing what that audience sees is how a technically correct system generates support tickets.

The useful test when reviewing a saga design: for each compensation, ask "who will notice, and what do they see?" If the answer is "nobody" the step was probably cleanly compensatable. If the answer names a human, you have found the part of the design that needs a product decision, not a retry policy.