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

You can share you thought with this squad 

Backend Developer 

A practical system design scenario where a mobile client retries a payment request three times due to network stalls, resulting in triple charges. Four approaches are presented to prevent duplicate payments: unique DB constraint on (orderId, amount), idempotency keys with cached responses, distributed locking via Redis SETNX, and SERIALIZABLE database transactions. Readers are challenged to identify which approach is used by Stripe, Shopify, and serious payments platforms, with a full breakdown promised in the comments.

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--kCzfdljM--/f_auto/v1778354244/ugc/content_b3fce7ed-9600-4814-833e-ef77ebe40ae6?_a=BAMAMiWQ0" alt="ChatGPT Image May 9, 2026, 09_42_00 PM (2).png">

Also, it would mean a lot to me if you could support my content and stay in touch 🙏
<ul>
<li>YouTube: <a href="https://www.youtube.com/@system-design-lab" target="_blank" rel="noopener nofollow">https://www.youtube.com/@system-design-lab</a></li>
<li>LinkedIn: <a href="https://www.linkedin.com/in/joud-awad/" target="_blank" rel="noopener nofollow">https://www.linkedin.com/in/joud-awad/</a></li>
<li>Medium Blog: <a href="https://joudwawad.medium.com/" target="_blank" rel="noopener nofollow">https://joudwawad.medium.com/</a></li>
<li>Substack: <a href="https://joudawad.substack.com/" target="_blank" rel="noopener nofollow">https://joudawad.substack.com/</a></li>
</ul>

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.