System design interview question

Design a notification system

Order updates, login codes, reminders, sale announcements: almost every product sends notifications, and “design a notification system” asks you to build the one shared service every team calls. It tests how you absorb bursts, retry against outside providers that fail, and never send the same thing twice. Here is how to walk into it, and then how to practise it until the answer is yours.

Practise Notification System

Multiple choicePick the design from four
Fill the gapsFill the gaps in one drawn for you
Build from scratchBuild it on a blank canvas

Practise it on a canvas

Free with an account.

The question, as an interviewer would set it

A company wants one internal service that every product team calls to notify customers — order updates, security alerts, reminders — by phone push, email or text message, depending on each customer's preferences. Teams fire requests in bursts of hundreds of thousands, for example when a sale starts, and the calling team must get an answer immediately rather than waiting for delivery. The outside email and text providers are slow and sometimes fail, so a failed send must be retried later without being lost, and nobody should ever receive the same notification twice. Preferences, such as a customer who has turned email off, change rarely but are checked on every send.

What it is really testing

Every phrase that matters in the brief is a requirement in disguise. Spot them before you draw a single box.

“must get an answer immediately rather than waiting for delivery”
Accept the request, put it in line, and answer before anything is delivered.
“in bursts of hundreds of thousands”
A buffer that absorbs the burst and workers that drain it at a steady pace.
“a failed send must be retried later without being lost”
A line that keeps each send until it is confirmed, and gives failures back.
“nobody should ever receive the same notification twice”
A record of what was sent, checked before every send.
“change rarely but are checked on every send”

Back of the envelope

Customers: 100 millionAn assumption to say out loud. If the interviewer has a number in mind, they will give it to you.
Notifications: ~5 a day each → ~500 million a day, ~6,000 a secondThe average. The shape that matters is the burst.
A burst: 500,000 in the first minute of a sale → ~8,000 a secondOn top of the usual traffic, all at once, while the outside providers may accept far less.
Preference checks: One per send → the same ~6,000 a secondPreferences change rarely, so almost every one of those reads returns what it returned last time.

Questions to ask first

Which channels — phone push, email, text messages, in-app — and does each customer choose?
Are some notifications urgent, like a login code, and others bulk, like marketing?
Must every notification be delivered, or is best effort acceptable for some kinds?
How big are the bursts, and what causes them — a sale starting, a news event?
Do we need scheduling, such as “send at 9am in the customer's time zone”?

The trade-offs you will be pushed on

1.How does a calling team get an answer at once when delivery takes seconds, or fails?
2.An outside provider is slow or down. What happens to the sends waiting on it?
3.A send is retried after a crash. What stops the customer receiving it twice?

Now answer it

The same design always gets the same score, with the reason behind every requirement — then defend it against the trade-offs above.