Medium · Finance and payments
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. Practise this medium system design problem for free with a Google or GitHub account.
The brief
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.
Think of a pay-in-installments service like Klarna.
Users, scale and requirements
- Who uses it
- 2 million shoppers a month
- Audience in plain numbers
- 2,000,000 people per month
- Normal peak
- ≈ 3,000 requests per second
- Request mix
- Read: 40%; Sign-in: 15%; Payment: 20%; Write: 10%; Notification: 15%
- Speed for 99 of 100 requests
- Read: ≈ 400 ms; Sign-in: ≈ 1,000 ms; Payment: ≈ 5,000 ms; Write: ≈ 400 ms
- Successful requests
- 99.9%
- Data safety
- No acknowledged write may be lost.
- Monthly budget
- ≈ $8,700
- Data at rest
- ≈ 2 TB
- Where users are
- North America: 100%
- Home region
- North America
- Waiting deadlines
- Read: 900 seconds; Sign-in: 900 seconds; Payment: 3,600 seconds; Write: 3,600 seconds; Notification: 900 seconds
- Personal reads
- 90% of reads are private; a shared public copy cannot answer them.
- Required proofs
- Audit trail; Managed encryption keys; Consent records
≈ marks an approximation, just as in the game. Waiting deadlines measure the age of queued work and are separate from interactive response time.
- Each "payment" is a score plus the first installment charge.
- Reminders go out by push.
- Notification speed measures provider acceptance. Device receipt is outside this traffic model; check expiry, provider outcome and retries in the correctness trace before claiming delivery guarantees.
Questions that shape the design
How long does a shopper wait for a decision?
A few seconds. The score comes from your own model and the shopper's recent history.
What happens to the first card charge?
It can finish a little later. "Charge pending" is fine, charging twice is not.
Does the card processor ever slow us down?
Yes. It takes about 1,000 charges a second and sometimes halves that for an hour.
What does the regulator care about?
Proof the shopper agreed to the credit check, encryption and an audit trail.
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.
12:00 · Provider rate limit
An outside service lowers its configured request quota and answers 'too many requests' above the reduced limit.
Provider capacity falls to 50% of its configured quota. Duration: ≈ 3,600 seconds.
16:00 · Compliance audit
An auditor checks your design: who did what, encryption keys, personal data, backups and consent.
19:00 · Retry storm
A brief failure causes clients to retry, adding load while the service recovers.
Failed calls: 90%. Duration: ≈ 30 seconds. Duration: ≈ 1,200 seconds.
What a strong design has to handle
- The processor cannot keep up when it slows down. Who should be waiting: the shopper, your servers, or a line of saved charges?
- Bind a credit decision and initial charge to one recoverable purchase.
- A queue means the first charge may land 30 seconds late instead of 3. During a processor slowdown that is far better than a spinning wheel and a failed order.
- Retries with jittered backoff spread repeated calls over time. Retries without spacing turn a small slowdown into a storm.
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
- Easy
Invoicing and billing
Small businesses create invoices, email them to customers and take card payments online. On the last working day of the month everyone sends and chases invoices at once. Nobody may get the same invoice email twice, and no invoice may vanish.
- Easy
Payroll run
On pay day your system tells the payment rail to move salaries for two million employees, then publishes a payslip for each one. Employees open the app at breakfast to see if they were paid. Paying anyone twice is the one thing you must never do.
- Medium
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.
- 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.