Buying infrastructure without buying it twice
Networks fail at the worst moment. Idempotency keys make “try again” safe when real money is involved.
Engineering, November 8, 2026, 4 min read
Your script sends a checkout request. The connection drops. Did the order go through? If you retry and it already did, you have just bought twice. If you don’t and it didn’t, your job stalls. Neither is acceptable when the request spends money.
The fix: name the attempt, not the request
An idempotency key is a value you choose for one logical purchase and send with every attempt at it. The server remembers the first result for that key. Every retry with the same key gets the same answer — the original order — instead of a new one.
POST /v1/checkout
Idempotency-Key: nightly-price-run-2026-11-08
{ "quote_id": "q_…" }Choosing a good key
- Derive it from the job, not the clock: a run ID, a date plus a purpose
- Store it before the first attempt, so a crashed process retries with the same key
- Never reuse a key for a different purchase — the server will refuse it, and it should
It has to go all the way down
A safe checkout is only half the story. When we set up the resource with a network partner, we use a fixed reference for that order too, so a retry on our side can’t create a second resource. Safety that stops at the first API isn’t safety.