Engineers file idempotency under plumbing: a key, a dedupe check, a thing the framework mostly handles. Merchants experience it as something else entirely — the difference between a recovery tool and a liability. Retry a card twice by accident and you have not recovered revenue; you have double-charged a customer who was already having a bad week, and purchased a chargeback with your own money.
So in Swipe Again, the double-charge defense is architectural, not procedural: every attempt carries an idempotency key, a compare-and-swap claim on the payment row ensures exactly one worker owns an attempt, the payment's live state is re-read fresh from the platform before any charge fires, and a single choke point marks recovery so attribution can never double-count either. No checklist, no human vigilance — the unsafe path does not exist in the code.
The lesson worth stealing: safety properties that depend on people being careful fail at 3 a.m. during the incident you built them for. Make the dangerous operation unrepresentable and the recovery flow inherits the guarantee for free. Idempotency sounds like plumbing until the day it is the only thing standing between your product and your customer's angriest email. Then it is the feature.
Top comments (1)
Making the unsafe path unrepresentable is a useful way to frame this. One detail that may be worth clarifying is how the idempotency key is scoped: if the same key arrives with a different payload, does the system reject it or return the original result? Teams seem to handle that edge case differently, and it can affect how safely a client can retry after a timeout.