Idempotency Keys in Practice: Making Retries Safe

Networks fail in the middle of requests all the time. The client sends a payment request, the server processes it, charges the card, and then the response never makes it back — timeout, dropped connection, whatever. The client, seeing no response, retries. Now you've charged the customer twice.

This isn't a hypothetical edge case. It's the default behavior of every retry mechanism you've ever shipped unless you've explicitly designed against it. Idempotency keys are the standard fix, but most implementations I've seen get the details wrong — they store the key without storing the response, they don't handle concurrent retries, or they let the key collide across different request bodies. Let's fix that.