Notifications system design
Design a notification system for our apps.
The problem
A notification service sends push messages, emails and texts for other apps: order updates, login codes, news.
An app calls it with one message: who gets it, on which channel, and what it says.
Outside companies deliver the messages. Each one has its own speed and its own limit.
Questions to ask the interviewer
Which channels?
Push messages, emails and texts: 60% push · 30% email · 10% text.
How many a day, and at the peak?
- About 220 notify calls a second at the peak; each one sends one message.
- The app that calls must get its answer in under 200 ms on average.
Must a login code be fast?
Not yet: every message may arrive a few seconds late.
What if a provider is down?
It is another company: it can be slow or down for a while. For now, a late message is fine.
Can a user get the same message twice?
Better not. For now, nobody has complained.
What is the budget?
About $150 a month.
Want to try it yourself first? Play, then come back for the approach.
PlayThe design in short
A notification service sits between your apps and outside companies that deliver the messages. The apps want a quick answer. The outside companies are slow, each in its own way, and they set their own limits. The design is about not letting their pace become your pace.
Two clocks run at once. The calling app needs its answer in milliseconds. A push, an email or a text can take far longer to hand over. If your servers wait for the provider before they answer, the app waits too. So ask: what must happen before you answer the app, and what can happen after? Keep the first list short.
Each channel has its own pace. Push, email and text go to different companies, with different speeds and different limits. Learn the speed of each before you size anything.
Parts to think about:
- what the calling app waits for before it gets its answer
- how many messages each provider takes a second
- what happens to a message while its provider is busy
Reason about scale per channel, against each provider's pace. Split the peak calls by the share of each channel. Then compare each share with how fast its provider takes messages. The slowest channel is not always the smallest one, so check them all.
Be clear about the promise. The goal says every message must be sent. Think about what you have told the app when you answer, and what must then be true for that answer to be honest.
Questions worth asking the interviewer before you draw: which channels count, how many calls come at the peak, and how fast the app needs its reply. The brief answers each one; write the answers next to your sketch, so every box you add has a number to meet.
Lay out your design on the GonnaCrash whiteboard and watch the messages leave.
Last updated 22 October 2026