A saga refunds a payment as its compensation for a failed order. Someone reviewing the code asks why the refund doesn't just "undo" the original charge the way a database ROLLBACK would. What's the actual difference, and why does it matter for how compensations are designed?

A database ROLLBACK works because the transaction's changes were never committed — nobody else could have seen them, so discarding them leaves no trace. A saga's steps are different: T2 (charging the card) has already committed by the time T3 fails, and in the time between T2 committing and the compensation running, other things may have already observed and acted on that committed charge — the customer got a notification, a fraud system logged it, a downstream ledger booked it. There's no way to make it as if the charge never happened, because it did happen, visibly. So compensation isn't an inverse operation; it's a brand-new, independently visible forward action — a refund, dated after the original charge, appears on the customer's statement as its own line, not as the charge's disappearance. That distinction matters practically: it means a compensation has to work correctly against whatever the current state actually is, not against 'restore state to before T2', because state may have moved on in the meantime.