A user taps “Pay $499” on checkout.
The spinner hangs. They tap it again. And once more.
Three requests hit your Payments API. Two of them actually succeed. The customer is charged $1,497 and opens a support ticket before your on-call even sees the alert.
Here’s the setup:
Mobile → POST /payments { orderId: “ord_8821”, amount: 499 }
Network stalls on the first request → client retries twice
Your service receives 3 near-identical POSTs within 4 seconds
Stripe gets charged 3 times. Your DB writes 3 payment rows.
You have one sprint to make sure a retried request never double-charges again. What do you do?
A) Add a unique constraint on (orderId, amount) in the payments table — the second insert fails, problem solved.
B) Require the client to send an Idempotency-Key header; store the key + response and return the cached result on retry.
C) Put a distributed lock (Redis SETNX) around the payment handler keyed by orderId — only one request processes at a time.
D) Wrap the charge + DB write in a database transaction with SERIALIZABLE isolation — concurrent writes can’t both commit.
Three of these will stop some duplicates. Only one of them is what Stripe, Shopify, and every serious payments platform actually ships.
Pick one — A, B, C, or D — and tell me why. Full breakdown drops in the comments (including why two of the wrong answers are the exact mistakes I’ve seen in production post-mortems).
If your team has ever argued about how to make an endpoint “safe to retry,” send them this. That argument is worth having on purpose, not at 3am during an incident.
Drop your answer 👇
#30DaysOfSystemDesign #SystemDesign #DistributedSystems #SoftwareArchitecture

Star

Joud Awad

A practical system design question about preventing duplicate payment charges when a client retries a failed request. The scenario involves three near-identical POST requests hitting a payments API within seconds, resulting in triple charges. Four solutions are presented: unique DB constraint, idempotency keys, distributed Redis lock, and serializable DB transactions. Readers are challenged to identify which approach is used by Stripe, Shopify, and serious payments platforms.

4/30 Days System Design Questions!

Answer: B — Idempotency-Key header ✅
Here’s why, and why the other three are the exact mistakes I’ve seen in real post-mortems:
Why B wins (Idempotency-Key):
The client generates a UUID before the first request and attaches it as Idempotency-Key: 7f3e… on every retry of that same logical operation. Your server does the work once, stores {key → response} in a durable store (Postgres, DynamoDB, Redis with persistence — not plain Redis), and on any retry with the same key, it returns the original response without re-executing the charge.
Critical detail most people miss: you cache the full response (status code + body), not just “I saw this key.” If retry #2 arrives while retry #1 is still processing, you make it wait or return a 409 — never let two executions race with the same key.
This is exactly what Stripe (Idempotency-Key), PayPal (PayPal-Request-Id), Shopify, and AWS (ClientRequestToken on half their APIs) all ship. It’s the only approach that handles the full failure matrix: network retries, client-triggered retries, load balancer retries, and “the request succeeded but the response got lost” — which is the nastiest case and the one the other three options silently fail on.
<img src="https://media.daily.dev/image/upload/s--rrQlGXKQ--/f_auto/v1778352464/ugc/content_7343f3a7-77cf-4c91-9704-4193b518553d?_a=BAMAMiWQ0" alt="ChatGPT Image May 9, 2026, 09_42_00 PM (2).png">

Why A is the trap answer (unique constraint on orderId):
This is the answer I’ve seen in 4 different production codebases, and it’s wrong for a subtle reason.
A unique constraint stops the second insert from committing — good. But what about the first charge to Stripe? In most implementations, you call Stripe’s API first, then insert the payment row. So request #1 charges Stripe, DB insert succeeds. Request #2 charges Stripe again, then the DB insert fails with a constraint violation. The customer is now charged twice. Your DB looks clean. Your logs say “duplicate order prevented.”
Even if you flip the order (insert first, charge second), you’ve just moved the race condition — now retry #2 fails at the DB, but if retry #1 crashes between insert and charge, you have a payment row with no actual charge. Worse than double-charging. Silent money loss.
A unique constraint is a great defense-in-depth layer. It is not the primary mechanism.

Why C is wrong (distributed lock):
A Redis lock on orderId serializes the 3 retries so only one runs at a time. Sounds clean. But it only solves the concurrent case. It doesn’t help with sequential retries that arrive after the lock has already been released and the response was lost in transit.
Request #1 acquires lock, charges Stripe, releases lock, returns 200 — but the 200 never reaches the client because the connection died. Client retries 30 seconds later. The lock is long gone. You charge again.
Distributed locks are for preventing concurrent execution. Idempotency is for preventing repeated execution across time. Different problems.
Also: distributed locks are famously hard to get right. Martin Kleppmann’s “How to do distributed locking” post exists for a reason. Don’t reach for one unless you actually need the concurrency guarantee.

Kudos on sharing system design questions. Good read

Why D is wrong (SERIALIZABLE transaction):
SERIALIZABLE isolation is about protecting the database from concurrent-write anomalies. It has nothing to say about the external side effect — the charge to Stripe. Your transaction can roll back and your DB can be pristine, but the HTTP POST to Stripe already went out, and that money is gone.
This is the most common conceptual bug in the “make payments safe” category: treating the database as the boundary of correctness when the real boundary is the external side effect. The moment you call Stripe, the universe has changed. Your DB transaction can’t un-change it.