Compensating Transaction

A compensating transaction is an operation that reverses the business effect of an earlier operation that has already committed. It exists because once a step has committed in its own system, there is nothing left to roll back — so reversal has to be expressed as new work rather than as undoing old work.

The original saga paper describes compensation as a semantic reversal. It need not return the database to its earlier state, because unrelated transactions may have committed since the forward step.

Semantic undo, not physical restore

In the paper’s seat example, cancel the particular reservation and adjust the reserved-seat count under the current rules. Restoring the saved count from before that booking could erase reservations made by other customers in the meantime.

Writing back the old value would erase everyone else’s work. Time passed, other people booked, and the correct reversal is a relative operation — one fewer reservation — not an absolute one. Express the reversal as a business operation that preserves unrelated changes rather than blindly restoring a saved value.

Forward step	Compensation	Not this
Reserve stock	Release the reservation	Set the quantity back to what it was
Authorize or capture a payment	Void/release an uncaptured authorization; use an allowed refund for a captured payment	Delete the payment record
Create an invoice	Issue a credit note	Delete the invoice
Grant an entitlement	Revoke it, effective from a stated time	Restore the previous entitlement set

The third column is not only wrong about concurrency. Deleting the record also destroys the evidence that anything happened, which in a financial or regulated process is a defect in itself.

Designing one

A compensation is ordinary application code operating on live data, and it needs the same care as the forward path — more, in fact, because it runs when something has already gone wrong.

• Make it safe to repeat. Compensations are invoked by recovery logic that may itself have failed and retried, and a refund issued twice converts a failure into a loss. That is the idempotency requirement, and for an operation that is not naturally idempotent the usual mechanism is an idempotency key.
• Make it resumable, then give failure a path. Record progress durably and make repeated steps safe. Retry transient failures with spaced, bounded attempts. If a permanent error or deadline prevents completion, preserve the details and escalate to an accountable owner. Compensation can fail; the design must support both resumption and investigation.
• Leave a trace. The forward step and its reversal are both real business events. Recording both — rather than making the record look as though the first never happened — is what lets anyone later explain the sequence, and belongs in the audit log.
• Design notification and downstream correction. The original saga mechanism does not automatically notify or abort observers of intermediate state. A workflow can publish compensation events and contact affected people, but those actions need their own delivery and completion tracking. They cannot erase what someone already observed.
• Design compensation with the forward step. The paper permits registering compensation incrementally, by the time the corresponding step is ready to commit. Keep the reversal code, parameters, and progress available for recovery, or explicitly document why this step cannot be compensated.

Choosing the recovery boundary

The pivot is the workflow’s boundary between backward recovery and a commitment to forward completion. An irreversible step can define it, but Microsoft’s classification also permits the last compensable transaction or the first retryable operation to serve as that boundary.

A shipment is not automatically non-compensable if the business accepts a return; a settled payment can have an allowed refund. Decide which reversal the workflow promises and when it will stop choosing that reversal. Before crossing the pivot, validate critical conditions and reserve resources where possible. Afterward, safe retries require recoverable dependencies, and permanent failure still needs owned exception handling or manual completion.

Make these decisions explicit before accepting work. The following choices keep the irreversible step from dictating the recovery policy.

• Move the irreversible step later. Sequence the irreversible step as late as the process allows, so most failures occur while reversal is still possible.
• Gate the irreversible step. Put a check, an approval, or a delay immediately before it, since this is the last moment at which stopping is cheap.
• Decide whether the reversal is this saga’s compensation or a separate process. A return can be either: a compensating step the original workflow triggers and tracks, or its own workflow with its own approvals, timeline, and customer contact. Both are legitimate; what causes trouble is leaving it unstated, because then the original saga reports success while a reversal nobody owns is outstanding.

Four ways it goes wrong

• Restoring a stored value instead of applying the inverse operation, which silently discards concurrent changes. The seat example illustrates this concurrency failure.
• Deleting the record as a shortcut, which loses both the audit trail and anything else that referenced it.
• Compensating with no notification, when a person or another system acted on the intermediate state. A canceled reservation nobody was told about is a support call.
• Retrying a failing compensation forever, or giving up on the first failure. Both are wrong in the same way: no deadline. Resume from recorded progress with spaced attempts, and hand it to a person when a permanent error or a stated deadline is reached.

A last framing worth carrying. Compensation limits the damage of a partly executed process; it does not restore the world. Define completion through trustworthy business outcome evidence. Comparing records through reconciliation helps check the agreed relationship, but shared errors and unobserved real-world effects can remain. How the pieces fit together, and the guarantee compensation serves, are covered under saga and in Nothing Rolls Back.

References

• “Sagas,” Proceedings of the 1987 ACM SIGMOD International Conference on Management of Data
• Microsoft Azure Architecture Center, Saga Design Pattern
• Microsoft Azure Architecture Center, Compensating Transaction pattern
• Garcia-Molina and Salem, Sagas (SIGMOD 1987, pp. 249–259; Cornell-hosted paper)