Notification System

Push, email, SMS and in-app

The interview walk-through for a service that lets every team in a company notify users by push, email, SMS and an in-app inbox: scoping, sizing, the API, the data model, and the deep dives an interviewer steers toward.

Overview

In this interview you design the one service that every other team uses to reach users. The order service says 'order 123 shipped', the security service says 'here is your login code', marketing says 'send the spring sale to everyone in the US'. Your service decides which channels to use, what the text says in the user's language, when it may be sent, and then gets it through Apple, Google, an email provider and an SMS provider.

The mechanics (queues, retries, deduplication, the rules of APNs and FCM) are covered in the Notification System Design concept topic. This topic is the walk-through: how to scope the problem in the first five minutes, the numbers, the API and schema, and the deep dives interviewers pick, in the order you would present them.

Questions to ask first

Who calls the service? — Internal services only, through one API
Which channels? — Mobile push (iOS and Android), email, SMS, and an in-app inbox
How many users and notifications? — 100 million daily users, about 10 notifications each a day
Are some messages urgent? — Yes: login codes and security alerts within seconds; marketing may lag hours
Bulk sends? — Yes, campaigns to up to 20 million users
Can users opt out? — Per category and channel, plus quiet hours in their own time zone
Exactly once? — No duplicates the user can see; the inbox is the record

What you will be able to do

Scope the problem and size it, including the provider quota that caps a big send.
Present an API and a schema that make every send idempotent.
Explain priority lanes and why a login code must never queue behind a campaign.
Apply quiet hours in each user's time zone and collapse bursts into digests.
Plan a campaign to millions of users paced to provider limits, and survive a provider outage.

Key concepts

Notification API
Priority lanes
Templates and locales
Quiet hours by time zone
Frequency caps and digests
Campaign fan-out
Provider quotas
Idempotency keys
Circuit breaker

Functional requirements

One API for all teams: send to a user by template and category, with an idempotency key
Channels: push to every registered device, email, SMS, and an in-app inbox with unread counts
Respect per-user preferences by category and channel, quiet hours and frequency caps
Schedule a send for a time, including each user's local time
Campaigns: one request that reaches millions of users
Track each delivery: sent, failed, opened

Non-functional requirements

Urgent notifications (login codes) leave our system within 2 seconds at p99 (a target we chose)
Normal notifications within 30 seconds; bulk within the campaign's window
No lost notifications after the API returns 202; no visible duplicates
A slow or failed provider on one channel never delays another channel
Handle 5× the average rate at peak

Interview questions

Walk me through what happens when the order service sends a shipping notification.
How do you make sure a login code is never delayed by a marketing blast?
How would you send a campaign to 20 million users?
How do quiet hours work across time zones?
How do you stop users from getting too many notifications?
What happens when APNs, FCM or the SMS provider is down?
How do you track whether notifications were delivered and opened?
How would this system grow from a startup to a billion notifications a day?