Idempotency keys, briefly
[Placeholder] Making “at least once” safe to live with.
[Placeholder] Networks retry. Clients retry. Load balancers retry. If an operation isn’t safe to run twice, sooner or later it will run twice anyway.
The idea
[Placeholder] The client attaches a unique key to each logical operation. The server records the key with the result, and replays that result for any repeat.
- Key: generated by the client, once per operation.
- Scope: per user or per account, never global.
- Expiry: long enough to outlive every retry window.
The catch
[Placeholder] Storing the key and performing the side effect must happen atomically, or you’ve only moved the race somewhere harder to see.
About me
I’m from Bangladesh and have lived in Seattle long enough to call it home. I’ve run two half marathons and I’m training for a full one now. I write here about reliability, distributed systems, and running, which have more in common than you’d think.
I’m always happy to talk about AI/ML infrastructure, platform engineering, and the cool things you’re building:
Let's talk