A payment workflow that never double-charges
Design a Payment System, from a blank page
This is how the interview actually runs: one prompt, and you decide what to cover and in what order. Write each section, then compare it with a reference design and see what you left out.
A 45-minute round. You drive; nothing prompts you.
The prompt
You run checkout for a marketplace that sells online courses. Buyers enter card details into the payment provider's hosted fields, so your servers only ever see a short-lived payment token, never card numbers. Your backend creates an order, asks the provider to charge it, and, once the money has moved, grants the course and emails a receipt.
The provider behaves like every real one. Most charges finish in a second or two, a few take ten, and occasionally a request hangs until something times out. Some cards require a 3-D Secure challenge that completes minutes later. The provider accepts an idempotency key on every write and remembers it for 24 hours, sends signed webhooks for every state change, and lets you look up payments by your own reference.
Buyers double-click. Mobile connections drop mid-request. Your app servers are redeployed during business hours. Finance reconciles every day against the provider's settlement report, and they have found discrepancies before.
What the interviewer would tell you if you asked
- Provider latency: p50 1.5 s, p99 10 s; occasional hangs past 30 s. Rate limit 100 requests/second.
- Provider idempotency keys are retained for 24 hours.
- Webhooks are signed, delivered at least once, in no guaranteed order, retried with backoff for up to 3 days; the endpoint must answer within 10 s.
- Stateless app servers behind a load balancer with a 30-second request timeout; one Postgres database.
- About 5,000 orders a day, peaking at 50 a minute during course launches.
- Card data is tokenized by the provider's client SDK; you are out of scope for storing card numbers.
- The provider is the source of truth for whether money moved.
- The provider's API can look up a payment by your idempotency key or metadata reference.
- Server clocks are roughly synchronized but are not used to order events.
01
about 5 minWhat does the system have to do, and how well? List the functional requirements, then the non-functional ones (latency, availability, consistency, scale), and the questions you would ask the interviewer.
02
about 5 minTurn the volumes into the numbers that drive the design: requests per second at peak, storage, bandwidth, and anything else that decides whether one machine is enough.
03
about 10 minName the components and what each one is responsible for. Then trace the main request through them, and say where the durable state lives.
04
about 15 minPick the hardest decisions in this design and make them: what you chose, what you rejected, and which constraint decided it.
05
about 10 minWhat breaks? Walk through crashes, duplicates, slow dependencies and overload, and what the design does in each. Then: what changes at ten times the load, or with a new requirement?
Write something in at least 3 sections first. Gaps are fine; the comparison shows what they cost.