Notification System Design

Designing a system that notifies millions of users by push, email, SMS and an in-app inbox: the pipeline, fan-out, preferences and rate limits, the rules of APNs and FCM, retries without duplicates, and keeping tokens and addresses healthy.

Overview

A notification system takes events from the rest of the product, such as 'your order shipped' or 'Ana commented on your post', decides who should hear about them and how, and delivers them by mobile push, email, SMS or an in-app inbox.

Sending a single message is the easy part. The hard parts appear at scale and under failure. One event can fan out to millions of people. Every channel goes through an outside provider (Apple's APNs, Google's FCM, an email or SMS service) with its own rate limits and error codes. Queues redeliver messages, so without care users get the same alert twice. And users expect their preferences, quiet hours and unsubscribes to be respected every time.

Interviewers like this question because it touches queues, fan-out, idempotency, retries and third-party limits in one design, and because a good answer is mostly about what happens when something goes wrong.

What you will be able to do

  • Size a notification system and find its real bottleneck, often a provider quota.
  • Draw a queue-based pipeline with preferences, priorities and per-channel workers.
  • Choose fan-out on write, on read, or a hybrid for large audiences.
  • Deliver at least once without visible duplicates, with retries, backoff and a dead-letter queue.
  • Explain the delivery rules of APNs and FCM and keep device tokens and email addresses clean.

Key concepts

  • Channels: push, email, SMS, in-app
  • Queue-based pipeline
  • Fan-out on write and on read
  • Preferences and quiet hours
  • Priority lanes
  • APNs and FCM limits
  • At-least-once and deduplication
  • Backoff with jitter
  • Dead-letter queues
  • Token and bounce hygiene

Interview questions

  • Design a notification system for 50 million daily users.
  • How do you deliver at least once without sending duplicates?
  • Fan-out on write or fan-out on read?
  • How do you handle APNs and FCM failures?
  • Why add jitter to backoff, and how would you implement retries?
  • How do you respect user preferences and avoid spamming users?
  • Push notifications can be dropped. How do you make sure users do not miss anything?
  • How would you model and serve the in-app inbox?

Sign up free to read the full topic

More System Design topics

Start free on Cariara · Coding problems · System design studio