Medium · Core building blocks
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. Practise this medium system design problem for free with a Google or GitHub account.
The brief
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.
Think of the service that sends every push, email and text.
Users, scale and requirements
- Who uses it
- 30 million people a month
- Audience in plain numbers
- 30,000,000 people per month
- Normal peak
- ≈ 8,000 requests per second
- Request mix
- Notification: 70%; Analytics event: 20%; Write: 10%
- Speed for 99 of 100 requests
- Write: ≈ 300 ms
- Successful requests
- 99.9%
- Data safety
- No acknowledged write may be lost.
- Monthly budget
- ≈ $120,000
- Data at rest
- ≈ 2 TB
- Where users are
- North America: 60%; Europe: 40%
- Home region
- North America
- Waiting deadlines
- Notification: 1,800 seconds; Analytics event: 1,800 seconds; Write: 1,800 seconds
- Required proofs
- 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.
- Providers cap how fast you may send: push ≈ 10,000/s, email ≈ 1,000/s, text ≈ 100/s (approx.).
- Texts cost far more than email or 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
Does the sender wait until the message is delivered?
No. They only need to know it was accepted. Delivery happens afterwards.
What if the same message is asked for twice?
Send it only once. A double "your card was charged" text is a bad day.
Can a message be late?
A few minutes is fine for marketing, and up to half an hour while a provider is down; later than that it counts as failed. Login codes need seconds.
Do people opt out?
Yes. Check their preferences before every send.
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.
09: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 40% of its configured quota. Duration: ≈ 3,600 seconds.
13:00 · Duplicate delivery
The queue redelivers messages. Without duplicate protection, side effects may be applied twice.
Affected share: 3%. Duration: ≈ 3,600 seconds.
18:30 · Dependency outage
An outside service fails calls during an outage.
Failed calls: 100%. Duration: ≈ 1,200 seconds.
What a strong design has to handle
- The team asking should not wait for the message to go out. What can hold the work?
- Persist one logical delivery and reconcile ambiguous provider outcomes.
- A queue makes sending late but never lost. Without one, a slow provider slows every sender.
- At-least-once delivery plus an idempotency check gives "once" in practice and costs one extra lookup per message.
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
- 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.
- Easy
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.
- 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.
- 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.