Idempotency

You're buying a flight ticket. $847. You click the "Pay Now" button. The page freezes. Nothing happens for 5 seconds. You're not sure if it went through. So you click again.

Here's the million-dollar question (sometimes literally): did you just buy one ticket or two?

If the payment system isn't designed carefully, you just got charged $1,694. Two flights. Same seat. Double the charge. And now you're on the phone with customer support for 45 minutes trying to get a refund.

This isn't a hypothetical. Double-charges are a routine class of incident, and the reason is structural rather than careless: the retry that causes them is usually correct behaviour. Your browser retries. Your mobile network retries. Your payment provider's webhooks are delivered at least once by design, which means more than once is normal and expected. Every layer between the button and the ledger is built to try again, so the ledger is the layer that has to refuse to count it twice.

Idempotency is the property that prevents this. An idempotent operation produces the same result whether you execute it once or a hundred times. Click "Pay" once, click it ten times, you get charged exactly once. That's idempotency.

It sounds simple. It's deceptively hard to implement. And it's absolutely critical in any system that handles money, state changes, or anything you can't easily undo.

An operation is idempotent if performing it multiple times produces the same outcome as performing it once.

Let's ground this with everyday examples before we get technical.

Idempotent:

• Pressing an elevator button. Press it once, the elevator comes. Press it 50 times, the elevator still just comes once.
• Setting your thermostat to 72 degrees. Do it once or ten times, it's still 72 degrees.
• Turning off a light switch that's already off. Nothing changes. Do it again. Still nothing changes.

Not idempotent:

• Adding an item to your shopping cart. Click "Add to Cart" three times and you get three items.
• Sending an email. Click send three times and your recipient gets three copies.
• Withdrawing cash from an ATM. Hit "Withdraw $100" three times and you lose $300.

In HTTP Terms

The HTTP specification defines which methods are idempotent:

The key insight: GET, PUT, DELETE are naturally idempotent. POST is not. And POST is what you use for the most dangerous operations, creating orders, processing payments, sending messages.