Skip to content
System Designer

Easy · Government and education

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. Practise this easy system design problem for free with a Google or GitHub account.

The brief

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.

Think of a state benefits site.

Users, scale and requirements

Who uses it
1.5 million applicants a year (approx.)
Audience in plain numbers
400,000 users or devices
Normal peak
≈ 300 requests per second
Request mix
Read: 54%; Write: 20%; Sign-in: 15%; Upload: 4%; Notification: 5%; Report: 2%
Speed for 99 of 100 requests
Read: ≈ 700 ms; Write: ≈ 700 ms; Sign-in: ≈ 1,000 ms; Upload: ≈ 5,000 ms; Report: ≈ 10,000 ms
Successful requests
99.5%
Data safety
No acknowledged write may be lost.
Monthly budget
≈ $8,500
Data at rest
≈ 10 TB
Where users are
North America: 100%
Home region
North America
Waiting deadlines
Read: 900 seconds; Write: 3,600 seconds; Sign-in: 900 seconds; Upload: 3,600 seconds; Notification: 900 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
Signed-in access; Tested backups; Audit trail; Managed encryption keys; 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.

  • Public agencies often have small budgets; cost counts.
  • A "write" is saving a draft or submitting an application.
  • 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

Can an application be lost?

No. Someone may be applying for help to eat. A saved form must stay saved.

How fast must an email "we got your application" go out?

Within minutes. It can wait in a line when the site is busy.

When is it busy?

The closing days of a month can bring four times the usual traffic over several hours.

Who looks at the forms afterwards?

Caseworkers, through an admin tool that runs heavy reports.

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.

  1. 10:00 · Compliance audit

    An auditor checks your design: who did what, encryption keys, personal data, backups and consent.

  2. 12:00 · Deadline surge

    Tax day, enrollment close or a sign-up deadline. Traffic climbs for hours until the cut-off.

    Traffic reaches 4 times the scheduled load; rises over 21,600 seconds, holds for 3,600 seconds and eases over 900 seconds.

What a strong design has to handle

  • Which work can wait a few minutes without anyone minding?
  • Pointing the caseworker reports at a replica keeps the heavy queries away from people saving forms, at the price of a second database.
  • Synchronous copies make saves a few milliseconds slower and mean a zone failure cannot lose an application.

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