Read the printed FastAPI handler in execution order. It selects on the key, finds nothing, inserts a record with status `processing`, commits, and only then calls `payment_gateway.charge(body)` inside a try block [13]. That commit before the money moves is the good part of the design: it publishes the key to every other database connection before the gateway can be reached [9].
Now send the retry two hundred milliseconds later, while the charge is still open. The second request finds the record, compares hashes, and returns `existing.response_body` with `existing.status_code` [12]. Neither field has been written yet [21]. The client asked for an order id and gets an empty body with no status. The `status` column is in the record and nothing in the handler reads it [21]. A duplicate landing in that window wants a 409 and a backoff hint; the replay path is only correct once the record says `completed` [14].
The race between two simultaneous first requests is handled, but by the schema rather than by the code. `key VARCHAR(64) PRIMARY KEY` [7] means the loser's insert fails at `db.commit()`, and that commit sits outside the try/except in the snippet [13], so the loser raises instead of replaying [22]. Catch the constraint violation, re-read the row, and fall into the replay branch.
Where the key comes from is the part that costs you a client release. The rule in the post is one key per user action, resent on every retry [4]. The generator therefore sits above the retry loop, not inside it. A key minted per HTTP attempt is just a request id, and it will happily store three rows for three attempts at one payment.
Sizing is tight but adequate. The example key is a canonical UUID [19], which is 32 hex digits plus four hyphens, so 36 characters against a 64-character column, leaving 28 spare [20]. Fine for raw UUIDs. Thin if someone later prefixes a tenant id or composes the key from user id plus cart version.
The two snippets do not agree on how to fingerprint the body. FastAPI hashes `json.dumps(body, sort_keys=True)` with sha256 [15]; Flask compares the built-in `hash()` of the parsed dict [16]. Only the sha256 form is stable across worker processes and restarts, which is exactly the condition you are in when the retry lands on a different pod from the original. `sort_keys` earns its place for the same reason: two encoders that order keys differently would otherwise produce two digests for one request.
The most durable line in the whole post is the one marked optional: `CREATE UNIQUE INDEX orders_idempotency_key_idx ON orders (idempotency_key)` [8]. The keys table is a cache when it lives in Redis under a 24 to 72 hour TTL [17]. The index is a constraint with no expiry. Flush the cache, repoint at a new instance, lose the TTL argument in a config change, and the index still refuses a second order row for a key it has already seen. I would ship the index first and the replay table second, because the index degrades to a 500 and a support ticket while the missing replay table degrades to a second charge.
Rafi's framing of the stakes is a claim about detection latency: finance notices before engineering does [2]. He says he has debugged production checkout flows [24], and that ordering matches mine. A duplicate charge is visible in the gateway's own records within a day. It is visible in your orders table only if something is counting.
