Notifications across email, push and in-app
Design a Notification System
Product events become emails, push notifications and inbox items for millions of users. Respect every preference immediately, never notify twice, survive provider outages, and get the security alert out while a five-million-email announcement is in flight.
Intermediate, about 50 minutes, 11 stages
The situation
You own notifications for a project-management product with five million users. People are notified when they are mentioned, assigned an issue, or someone comments on something they follow. Security events (a new login, a password change) must reach them quickly. Marketing occasionally announces features to everyone.
Notifications go out by email (through a provider with a 500 sends/second account limit), mobile push (APNs and FCM) and an in-app inbox. Users choose, per notification type and channel, what they want, and set quiet hours.
Today, each product service sends its own emails inline. Last week an email-provider outage made commenting fail for twenty minutes, and users regularly complain about duplicate notifications.
What it has to do
Functional
- Mentions, assignments and comments notify the affected users on their preferred channels.
- Security notifications are always sent by email, immediately, regardless of preferences.
- Users set per-type, per-channel preferences and quiet hours.
- An in-app inbox lists every notification with read state.
- Marketing can announce to all users.
Non-functional
- A user is not sent the same notification twice on the same channel.
- Security emails go out within 30 seconds, even during a full-audience announcement.
- Provider outages delay notifications but never lose them.
- Unsubscribes and preference changes take effect immediately.
- Notification failures never slow down or fail the product action that triggered them.
Constraints and assumptions
- About 2 million product events a day fan out to ~8 million notifications, with work-hour peaks around 10x the average rate.
- Email provider: 500 sends/second account-wide, no idempotency keys, responses take 50 ms to several seconds.
- Push providers accept high throughput but report invalid device tokens per send.
- A managed queue, Postgres and Redis are available; product services already write events through a transactional outbox.
- Each product event has a unique, stable id.
- Users may have several devices, each with its own push token.
- Legal unsubscribe handling for marketing email is required in addition to in-app preferences.
Interview questions it prepares you for
- “Design a notification system.”
- “How would you send an email to every user without affecting transactional email?”
- “Users are getting duplicate push notifications. How do you investigate and fix it?”
- “Design a system that respects user notification preferences at scale.”
Read and practise next
How Uber built it · Push instead of polling, in their engineers' own words
Concepts to know first: Asynchronous processing, Idempotency, Message queues.
Similar systems: Design a Video Processing Pipeline, Design an API Rate Limiter.