A saga step for a Payment service is 'charge customer $50.' What makes a good compensating transaction for this step, and why can compensating transactions rarely be an exact mirror-image undo of the original action?
answer
- new transaction, not a rollback
- semantic inverse not literal undo
- some effects aren't fully undoable
- compensations must be idempotent
- sequence irreversible steps last
basics
~20 sA good compensating action produces the opposite business effect (like a refund for a charge), not a literal undo, because by the time you need to compensate, other systems may have already seen and acted on the original change.
solid answer
~50 sA compensating transaction is a new, forward-moving transaction that semantically reverses the business effect of an earlier step - a refund for a charge, a stock release for a reservation, a cancellation notice for a booking. It can't be an exact mirror-image undo because the original transaction already committed and its effects may have propagated: money may have left your merchant account and be sitting with a payment processor, another customer may have already been offered the freed-up inventory, or a downstream system may have already read and acted on the committed state. So compensations must be designed as their own well-defined operations with their own semantics, must be idempotent (safe to retry), and ideally safe to apply even if some intervening event occurred. Some actions are only partially compensable (you can refund money but can't un-send a shipped package or un-send an email), which pushes designers to sequence irreversible steps last and add domain-specific mitigation rather than pretending a clean undo exists.
go deeper
Should know that compensation means a new undo-like action, not literally reversing the database, and give a simple example like refund-for-charge.
Should articulate why an exact mirror-image undo isn't possible (effects may have propagated) and know compensations need to be idempotent.
Should discuss sequencing irreversible steps last, designing compensations to be more reliable than the original action, and handling partial/non-compensable actions with mitigation.
Should connect compensation design to broader system guarantees - audit/compliance requirements, how compensation failures escalate operationally, and how domain modeling choices reduce how much needs compensating in the first place.
## Why compensations are the hard part Every step in a saga that mutates state and isn't the last step needs a **compensating transaction**, and designing these correctly is arguably the hardest and most domain-specific part of building a saga - unlike the happy-path steps, which usually map directly onto existing service operations, compensations are new operations you often have to invent. ## A compensation is not a rollback The core idea is that a compensating transaction is not a database rollback. By the time a saga decides it needs to compensate step k, transaction `Tk` already committed - it's durable, and depending on timing, other parts of the system may have already observed and reacted to that commit. Rolling back a committed transaction isn't something databases support across process boundaries, and even within one database, 'undoing' a commit after the fact by deleting rows destroys the audit trail and can violate constraints other transactions now depend on. So instead, a saga issues a new, **forward-moving local transaction** whose business effect cancels out the original one: - **'Charge $50'** is compensated by **'refund $50'** - a brand-new transaction, with its own ID, its own record in the ledger, and its own auditability, not a deletion of the charge. - **'Reserve 1 unit of inventory'** is compensated by **'release 1 unit of inventory,'** incrementing the available-stock counter back up - which is safe even if, in between, someone looked at the stock count and made a decision, because it's just another state-changing operation, not a time-travel undo. ## What a compensation cannot erase This distinction matters because of a subtlety: between the original step committing and the compensation running, real-world consequences can already have occurred that a compensation cannot erase. - If releasing inventory happens after another customer has already been shown 'in stock' and started their own checkout, the compensation restores the count but can't retroactively prevent that customer from having seen a stale state. - If a shipment has already left the warehouse, cancelling the order can trigger a return-to-sender process but can't make the truck not have left. This is why some saga steps are described as 'not fully compensable' - the best you can do is a substitute action that mitigates the damage (issue a return label, send an apology credit) rather than a true undo. Recognizing this up front changes saga design: an experienced designer sequences genuinely irreversible steps (physical shipment, sending an external notification, calling a non-idempotent third-party API with no cancel endpoint) as late as possible in the saga, ideally last, specifically to minimize the number of already-irreversible effects that could need compensating. ## The reliability bar compensations have to clear Compensating transactions also carry stricter reliability requirements than ordinary steps. 1. **They must be idempotent**, because the saga's own failure-handling logic (crash-and-retry, at-least-once messaging) can cause a compensation to be triggered more than once, and a non-idempotent refund could double-refund a customer. 2. **They're also expected to be far more reliable than the original operation** - practically, teams design compensations to almost never fail (e.g., crediting an internal wallet balance is more reliable than reversing a real card charge with an external processor). 3. **When a compensation does fail**, the standard fallback is aggressive retry with backoff, and eventually a dead-letter queue with alerting for manual intervention, because an un-compensated saga leaves the system in a genuinely inconsistent state that automation alone can't always resolve. ## A production example A concrete production example: an airline booking saga reserves a seat, charges the fare, and issues a ticket. If ticket issuance fails after the charge succeeds, the compensation isn't 'delete the charge row' - it's a full refund transaction routed through the payment processor's refund API (which itself takes days to settle on the customer's statement, a real-world timing detail the saga design has to account for), plus releasing the held seat back into inventory so another customer can book it. Getting this wrong in production directly causes overbooking or double-refund incidents - for instance, a non-idempotent seat-release compensation that gets retried and increments available seats twice - which is exactly the class of bug that makes compensating-transaction design, not the happy path, the part of a saga implementation that gets the most scrutiny in review.
- Why must compensating transactions be idempotent specifically?Because the messaging or retry mechanism driving the saga typically offers at-least-once delivery, so a compensation can be triggered more than once - a timeout followed by a retry, or a crash-and-resume replaying an already-issued compensation. If 'refund $50' isn't idempotent, running it twice refunds $100, so it needs a way (like an idempotency key tied to the original transaction) to recognize and no-op a duplicate.
- How do you handle a saga step that genuinely can't be compensated, like sending a physical package?Sequence it as late as possible in the saga so as few things as possible could still fail after it, and treat its 'compensation' as a mitigation rather than an undo - trigger a return-to-sender or reverse-logistics process, issue a partial refund or store credit, and notify the customer, rather than pretending the shipment can be un-sent.
- Should a compensating transaction ever be more complex than the original transaction?Sometimes, yes - a compensation can need extra logic the original step didn't, like checking whether the item was already delivered before deciding whether to issue a refund versus arranging a return. But well-designed systems try to keep compensations simpler and more reliable than the original step where possible, since compensations are the safety net and a fragile safety net undermines the whole pattern.
It's like returning a purchased item to a store: the store doesn't erase the fact that you ever bought it, they process a separate return transaction that credits you back - and if you already ate the sandwich you bought, no return transaction can un-eat it.
saying these in an interview costs you the question
- Describes a compensating transaction as deleting or rolling back the original record
- Assumes every action has a clean, automatic undo
- Doesn't mention idempotency as a requirement for compensations
- Can't give an example of a step that isn't fully compensable
- Thinks compensation happens 'for free' without being explicitly designed and tested per step