Hard · Government and education
Tax filing deadline
A national tax site lets 30 million people file online. Most wait until deadline day, and traffic climbs all evening to a final-hour rush. People upload forms, check what they owe and pay. A mistake in a payment or a leak of tax data is a national story. Practise this hard system design problem for free with a Google or GitHub account.
The brief
A national tax site lets 30 million people file online. Most wait until deadline day, and traffic climbs all evening to a final-hour rush. People upload forms, check what they owe and pay. A mistake in a payment or a leak of tax data is a national story.
Think of a national tax filing site.
Users, scale and requirements
- Who uses it
- 30 million filers over the season (approx.)
- Audience in plain numbers
- 30,000,000 users or devices
- Normal peak
- ≈ 8,000 requests per second
- Request mix
- Read: 49%; Write: 22%; Sign-in: 15%; Notification: 1%; Upload: 6%; Payment: 4%; Report: 3%
- Speed for 99 of 100 requests
- Read: ≈ 700 ms; Write: ≈ 700 ms; Sign-in: ≈ 1,000 ms; Upload: ≈ 4,000 ms; Payment: ≈ 3,000 ms; Report: ≈ 10,000 ms
- Successful requests
- 99.9%
- Data safety
- No acknowledged write may be lost.
- Monthly budget
- ≈ $260,000
- Data at rest
- ≈ 80 TB
- Where users are
- North America: 100%
- Home region
- North America
- Waiting deadlines
- Read: 900 seconds; Write: 3,600 seconds; Sign-in: 900 seconds; Notification: 900 seconds; Upload: 3,600 seconds; Payment: 3,600 seconds; Report: 3,600 seconds
- Minimum retained history
- 2,555 days on authoritative stores
- Fresh reads
- People must see their own changes. At most 0.1% of reads may be stale in the model.
- Personal reads
- 80% of reads are private; a shared public copy cannot answer them.
- Required proofs
- Audit trail; Managed encryption keys; Personal data isolated; Tested backups; Signed-in access; Retention rules
≈ marks an approximation, just as in the game. Waiting deadlines measure the age of queued work and are separate from interactive response time.
- The deadline-day curve climbs to 1.0 at 23:30, and an extra rush on top triples the last stretch.
- A "write" is saving a draft or submitting a return.
- Scored data retention: at least 2555 days on active authoritative stores. Copies used only for search or reports can be rebuilt. Local device history and rollup policies still require the separate protocol check.
- 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
When is the rush?
The deadline is 23:30 on the last day. Traffic builds from the afternoon and peaks in the final hour at about three times the already high evening level.
Can a payment be taken twice?
Never. Every payment must happen exactly once, even when the person presses pay again or their phone retries.
What if the identity-check provider rate-limits us?
It happens in the rush. Sign-ins that cannot be verified right now must wait, not fail forever.
What does an auditor ask for?
Proof of an audit trail, encryption, isolated personal data, backups, signed-in access and retention for years.
The traffic day
Traffic builds toward a deadline. The clock covers 00:00 to 24:00 in the home region. Events add pressure on top of that normal traffic.
15:00 · Compliance audit
An auditor checks your design: who did what, encryption keys, personal data, backups and consent.
18: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 14,400 seconds, holds for 3,600 seconds and eases over 600 seconds.
22: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
- The load arrives slowly and then all at once. What element adds servers as the day builds, and why will it still be late?
- Issue durable filing receipts and reconcile payments independently of deadline retries.
- Autoscaling takes a few minutes to add servers, so the design pre-sizes to 20 and scales on a climb that starts hours early. A sudden minute-long jump would still hurt.
- The queue lets the site accept a return in a moment and finish processing it later; the person sees "received" and gets a confirmation after.
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
Benefits application portal
People apply for food, health or housing help on a state site. Forms are long, people save drafts and upload documents, and a caseworker team reviews each one. The last week of the month is busy, and an auditor checks the privacy and access controls once a year.
- Medium
Insurance claims
After a hailstorm, thousands of drivers file claims online, each with a handful of photos. The storm offer ends at 5 pm, so everyone files at the last minute. Every claim must be saved safely, and every customer gets a confirmation email.
- Medium
Smart power grid
A power company has 5 million smart meters. Each reports usage every 15 minutes, and they all try on the quarter hour. Customers see their usage, billing needs exact totals for seven years, and a regulator checks that records are kept safely. Control commands to home batteries and thermostats must never run twice.
- Medium
CI/CD build system
Every time a developer saves code to the shared repository, you build and test it. Thousands of developers do this all day, and release day brings a rush. Builds must start quickly, but idle build machines cost real money.