Compensating Transaction
A business operation that semantically undoes a previously committed step — not a rollback, because the original effect was visible and may not be fully reversible.
The distinction from rollback is the whole design problem. A database rollback leaves no trace; a compensating transaction is a new, visible business event. A refund is not an un-charge: the customer saw the charge, the statement records both, and the money moved twice.
Three consequences shape saga design:
Some steps cannot be compensated at all. An email has been read, a physical item has shipped, a regulatory report has been filed. This is why saga step ordering matters — put irreversible steps last, so failure before them requires no impossible undo.
Compensations must themselves be idempotent and retryable, because the compensation can fail too, and giving up leaves the system in the inconsistent state the saga existed to avoid.
Compensation may need to handle intermediate observations. If another process read the state between the step and its compensation, and acted on it, the undo is incomplete. The usual answer is a "pending" or "reserved" state so intermediate readers know not to rely on it.
The design question for every step: if this succeeds and a later step fails, what exactly do we do, and is it acceptable to the customer?