Easy · Healthcare
Lab results portal
Labs send results to a portal, patients get a notice that a result is ready and open it. When the notice goes to thousands of people at the same minute, they all open the portal at once. Nobody should get the same notice twice. Practise this easy system design problem for free with a Google or GitHub account.
The brief
Labs send results to a portal, patients get a notice that a result is ready and open it. When the notice goes to thousands of people at the same minute, they all open the portal at once. Nobody should get the same notice twice.
Think of a patient portal that shows blood test results.
Users, scale and requirements
- Who uses it
- 1.2 million patients a month (approx.)
- Audience in plain numbers
- 1,200,000 people per month
- Normal peak
- ≈ 700 requests per second
- Request mix
- Read: 58%; Sign-in: 15%; Write: 12%; Notification: 12%; Report: 3%
- Speed for 99 of 100 requests
- Read: ≈ 700 ms; Sign-in: ≈ 1,000 ms; Write: ≈ 700 ms; Report: ≈ 10,000 ms
- Successful requests
- 99.9%
- Data safety
- No acknowledged write may be lost.
- Monthly budget
- ≈ $12,000
- Data at rest
- ≈ 2 TB
- Where users are
- North America: 100%
- Home region
- North America
- Waiting deadlines
- Read: 900 seconds; Sign-in: 900 seconds; Write: 3,600 seconds; Notification: 300 seconds; Report: 3,600 seconds
- Personal reads
- 95% of reads are private; a shared public copy cannot answer them.
- Required proofs
- Signed-in access; Tested backups; 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.
- A "write" is a lab sending a result in.
- A "report" is a clinic printing a monthly summary.
- 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 fast must a notice go out?
Within a few minutes of the result arriving. It can wait a little, but never be sent twice.
Do many patients open the portal at the same time?
Yes. A weekday 7 am batch of results notifies thousands at once, and about ten times the normal traffic arrives within a minute.
Can the queue ever deliver a message twice?
Yes, queues occasionally deliver the same message again, about 1 in 100 here. The notice step has to cope.
Who is sending the results?
Partner labs, through an approved connection.
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.
03:00 · Duplicate delivery
The queue redelivers messages. Without duplicate protection, side effects may be applied twice.
Affected share: 1%. Duration: ≈ 3,600 seconds.
07:00 · Flash crowd
A scheduled launch brings a sudden rush of requests.
Traffic reaches 10 times the scheduled load; rises over 60 seconds, holds for 600 seconds and eases over 1,200 seconds.
What a strong design has to handle
- Most traffic is reading the same result list again and again. What remembers an answer for a minute?
- A 60-second cache keeps the database calm in the rush and means a brand-new result can take up to a minute to appear for a patient who already looked.
- The idempotency store costs about $100 a month and removes the one embarrassing failure: a patient getting the same alert three times.
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
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.
- Hard
Black Friday marketplace
Once a year a marketplace puts thousands of deals live at the same minute. Millions browse and search, a few doorbuster items get hammered, and a smaller crowd checks out. A payment must never be taken twice, and the day must survive the card processor having a bad hour.
- Hard
Video upload pipeline
Creators upload videos that must be converted into several qualities before anyone can watch. Conversion is slow, costs real money per video, and the converter sometimes fails on a broken file. Nothing a creator uploads can be lost.