Saga Compensation Design
Designing the undo actions for a distributed transaction, where compensation is a new business action rather than a rollback.
The conceptual shift that makes sagas workable: you cannot roll back a committed local transaction in another service, so you issue a compensating action that semantically reverses it. A payment is not un-taken, it is refunded. An email is not un-sent, a correction is sent.
That distinction has consequences the pattern's diagrams do not show. Compensation is visible — the customer sees a charge and a refund — so the business must accept the intermediate state. Compensation may fail, and a failed compensation needs escalation to a human rather than an infinite retry. Some actions are not compensable at all: a dispatched physical shipment, a disclosed piece of information, a message delivered to a third party.
The design rules that follow. Order the steps so that non-compensable actions come last, after everything reversible has succeeded — which is the single most useful piece of saga design advice and is frequently violated. Use reservations for scarce resources rather than commitments, so the compensation is releasing a hold rather than reversing an allocation. Make every step and every compensation idempotent, since both will be retried. And ensure the saga's state is durable, so an orchestrator crash mid-flow resumes rather than abandoning a half-completed transaction.
The operational requirement that gets omitted: visibility into in-flight sagas, and a means to intervene manually. Some will get stuck, and without an operator interface the resolution is a developer writing database updates during an incident.