Easy · Finance and payments
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. Practise this easy system design problem for free with a Google or GitHub account.
The brief
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.
Think of an invoicing tool like QuickBooks.
Users, scale and requirements
- Who uses it
- 300,000 small businesses and their customers
- Audience in plain numbers
- 1,200,000 users or devices
- Normal peak
- ≈ 800 requests per second
- Request mix
- Read: 59%; Write: 20%; Report: 10%; Payment: 10%; Notification: 1%
- Speed for 99 of 100 requests
- Read: ≈ 400 ms; Write: ≈ 400 ms; Report: ≈ 3,000 ms; Payment: ≈ 3,000 ms
- Successful requests
- 99.5%
- Data safety
- No acknowledged write may be lost.
- Monthly budget
- ≈ $5,500
- Data at rest
- ≈ 1 TB
- Where users are
- North America: 100%
- Home region
- North America
- Waiting deadlines
- Read: 900 seconds; Write: 3,600 seconds; Report: 3,600 seconds; Payment: 3,600 seconds; Notification: 900 seconds
- Personal reads
- 90% of reads are private; a shared public copy cannot answer them.
≈ marks an approximation, just as in the game. Waiting deadlines measure the age of queued work and are separate from interactive response time.
- An invoice page is about 4 KB; a PDF copy is made later.
- Month-end brings about 3 times the normal peak.
- 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
Can an invoice be edited after it is sent?
Only by issuing a new version. Every version is kept, so every write is a durable new record.
Do emails have to arrive instantly?
Provider acceptance within 120 seconds is fine. Use a stable provider key and reconcile unknown outcomes after a crash. Without provider support, one external email delivery cannot be guaranteed.
Who takes the card payment?
A payment provider. It is the slow part: about half a second typically, and it limits how fast you may call it.
The traffic day
Traffic concentrated in working hours. The clock covers 00:00 to 24:00 in the home region. Events add pressure on top of that normal traffic.
09:00 · Duplicate delivery
The queue redelivers messages. Without duplicate protection, side effects may be applied twice.
Affected share: 1%. Duration: ≈ 3,600 seconds.
10:00 · Deadline surge
Tax day, enrollment close or a sign-up deadline. Traffic climbs for hours until the cut-off.
Traffic reaches 3 times the scheduled load; rises over 21,600 seconds, holds for 3,600 seconds and eases over 600 seconds.
15: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.
What a strong design has to handle
- Emails do not need to be sent while the customer waits. What could take a message and let someone else deliver it?
- The cache makes invoice pages fast and cheap, but a page can be up to 5 minutes behind the last edit. Invoices rarely change, so that is fine here.
- The queue means "sent" really means "accepted"; delivery follows seconds later. In return the email provider never sees a burst.
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
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
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.