Idempotency keys for “create” endpoints

5824
0

Retries are inevitable: mobile clients, flaky networks, and load balancers will resend POST requests. Without idempotency you end up double-charging or double-creating records. I store an Idempotency-Key with a sha256 hash of the request body and the resulting response payload. If the same key arrives with a different payload, I treat it as a client bug and return a 409 instead of guessing. I also keep the TTL long enough to cover real retry windows (minutes to hours, not seconds). The big win is that I can safely enable aggressive retries at the edge without duplicating side effects, and incident response is easier because I can reason about replays deterministically.