Medium · Finance and payments
Checkout payments
Online shops send you their customers at the moment they pay. You call a card processor, record the order and answer in a couple of seconds. When the processor is slow or down, shoppers refresh and tap Pay again. Practise this medium system design problem for free with a Google or GitHub account.
The brief
Online shops send you their customers at the moment they pay. You call a card processor, record the order and answer in a couple of seconds. When the processor is slow or down, shoppers refresh and tap Pay again.
Think of a checkout like Stripe Checkout.
Users, scale and requirements
- Who uses it
- 8 million shoppers a month
- Audience in plain numbers
- 8,000,000 people per month
- Normal peak
- ≈ 2,000 requests per second
- Request mix
- Read: 50%; Write: 15%; Payment: 20%; Sign-in: 15%
- Speed for 99 of 100 requests
- Read: ≈ 300 ms; Write: ≈ 300 ms; Payment: ≈ 3,500 ms; Sign-in: ≈ 1,000 ms
- Successful requests
- 99.9%
- Data safety
- No acknowledged write may be lost.
- Monthly budget
- ≈ $5,200
- Data at rest
- ≈ 2 TB
- Where users are
- North America: 70%; Europe: 30%
- Home region
- North America
- Waiting deadlines
- Read: 900 seconds; Write: 3,600 seconds; Payment: 3,600 seconds; Sign-in: 900 seconds
- Personal reads
- 80% of reads are private; a shared public copy cannot answer them.
- Required proofs
- Managed encryption keys; Audit trail
≈ marks an approximation, just as in the game. Waiting deadlines measure the age of queued work and are separate from interactive response time.
- The processor itself is paid from revenue and is not in this budget.
- Peak is early evening.
Questions that shape the design
What happens if the shopper taps Pay twice?
They must be charged once. Every attempt carries a unique key from the browser.
If the processor is down, should checkout fail?
Better to say "payment pending" and settle after than to lose the sale, as long as nobody is charged twice.
Is card data sensitive?
Yes. Payments need an audit trail and keys held in a key service.
How slow is the processor?
About 0.4 s typically and 2 s at the slow end. It accepts about 1,000 charges a second for you.
The traffic day
Consumer traffic, busiest in the evening. The clock covers 00:00 to 24:00 in the home region. Events add pressure on top of that normal traffic.
10:30 · Duplicate delivery
The queue redelivers messages. Without duplicate protection, side effects may be applied twice.
Affected share: 1%. Duration: ≈ 3,600 seconds.
13:00 · Slow dependency
An outside service slows down. Your servers fill with requests waiting on it.
Added response time: ≈ 3,000 ms. Duration: ≈ 1,800 seconds.
19:30 · Dependency outage
An outside service fails calls during an outage.
Failed calls: 100%. Duration: ≈ 1,200 seconds.
What a strong design has to handle
- When the processor is slow, your servers wait on it and run out of room for everyone else. How do you stop waiting?
- Resolve unknown charges and keep order state consistent with payment state.
- Synchronous is simpler and gives instant "paid" or "declined". Its weak spot is a full outage: while the processor is down, nobody can pay.
- Asynchronous survives an outage and smooths bursts, but the shopper has to accept "pending", and your support team has to explain it.
Make a prediction, run a full traffic day, then compare the result. The in-game editorial opens after a finished day and includes measured reference designs.
Concepts to practise
Related problems
- Medium
Buy now, pay later
At checkout a shopper picks "pay in four". You score the shopper in a few seconds, then charge the first quarter on their card. The card network sometimes asks you to slow down, and when apps retry, the retries make it worse.
- Medium
Notification service
Every other team asks you to send messages: order shipped, new login, a sale starting. You send them by push, email and text through outside providers who have their own limits. Send each message once, and never block the team that asked.
- Hard
Scheduled job service
Customers register jobs: "call my web address every night at 02:00" or "every hour on the hour". Aim to fire within 5 seconds; work still waiting after 60 seconds counts as failed. Retry safely after a crash. One external effect requires the customer endpoint to honor a stable job occurrence key. Half the world picks the top of the hour, so a huge crowd of jobs comes due in the same second.
- Medium
One-to-one chat
People send short messages to each other from their phones. A message must arrive once, in order, even when the phone is on a bad connection and sends it again. If the other person is offline, the message waits and a notification goes out.