When designing the compensating step for a saga stage — say, 'release reserved inventory' to undo an earlier 'reserve inventory' step — what makes some compensations straightforward and others genuinely hard or impossible to write correctly?

## A new operation, not a rollback A compensating transaction is not a database rollback — there is no undo log spanning services the way there is inside a single ACID transaction. It's a deliberately authored, forward-moving business operation whose purpose is to semantically cancel the observable effect of an earlier saga step. This distinction matters because it changes how you have to think about designing one: instead of asking "how do I reverse this write," you have to ask "what new operation makes the world consistent again, given that the original operation already happened and other things may have happened since." ## The easy end of the spectrum The easy end of the spectrum is when a step's effect is entirely internal to the owning service's data and structurally reversible: - a "reserve 2 units of `SKU-123`" step decrements an `available_quantity` counter and inserts a reservation row; - its compensation, "release reservation," deletes the reservation row and increments the counter back. Nothing outside the service's database was touched, no third party was informed, and the operation is symmetric — you can write it, test it, and reason about it almost like a mathematical inverse. ## The hard end of the spectrum The hard end is when the original step had an effect that left the system's boundary: - money moved to a third party; - a physical action was triggered; - or a human was notified. Consider a step that calls a card network to capture a payment: the compensating step, "refund," is not truly symmetric — it's a new transaction that returns funds, but it may take days to settle, may incur different fees than the original charge, and shows up as two separate ledger entries rather than one that never happened, which matters for accounting and tax reporting. Now consider a step that sends a "your order has shipped" email or SMS: there is no API call that unsends a message a human has already read. The best you can do is compensate with a different kind of action entirely — send a follow-up correction, and design the original step so the irrevocable action (the send) happens as late as possible in the saga, ideally after all the steps that are more likely to fail have already succeeded, specifically to minimize the number of scenarios where you'd need to compensate for something unsendable. This is a general design principle: **order saga steps so that the truly hard-to-compensate steps run last, and the easily reversible steps run first**, so failures are statistically more likely to occur before you've done anything irreversible. ## Concurrency and timing A second class of difficulty is concurrency and timing. If a compensation for "reserve inventory" fires while the original reservation step is still technically in flight (e.g., the orchestrator issued the compensating command based on a timeout, but the reservation actually succeeds moments later), you can end up compensating something that hasn't happened yet, or racing the compensation against the original step's own retry. This is usually handled with a **semantic lock**: the reserved row is marked with a state flag (e.g., `PENDING_CONFIRMATION`) that other transactions — including a stray compensation — must check before acting, so a late-arriving compensation for a step that actually succeeded is either rejected or converted into the correct "release" action rather than silently corrupting state or running twice. ## Idempotency under redelivery A third difficulty is **idempotency under redelivery**: because saga coordination runs over unreliable messaging, the same compensating command can be delivered more than once (a retry after a timeout that actually succeeded, or a redelivery from an at-least-once broker). The compensation must be safe to execute twice — releasing an already-released reservation should be a no-op, not an error or a double-increment of the counter — which usually means keying the operation by an idempotency key (e.g., the original reservation ID) rather than by a raw "add N back" instruction. ## When nothing can compensate The genuinely impossible case is when the original step's effect can't be compensated by any business-level operation at all — most classically, a legally or physically final action, like a non-refundable, non-cancelable third-party booking, or data that has already been disclosed to another party in a way that can't be recalled. Here the saga design has to change: 1. either make that step the very last one in the sequence (so nothing after it can fail and require compensating it); 2. require manual/human intervention as the "compensation" (a support ticket, a customer-service credit); 3. or restructure the business process to avoid ever needing to undo it. A concrete real-world example: airline booking sagas typically place the actual seat-lock/ticket-issuance step as late as possible and put the truly irreversible fare-rule-locked purchase confirmation last, precisely because a ticket, once issued against certain fare classes, is either non-refundable or refundable only through a separate, slower, fee-bearing process rather than a clean compensating transaction.