Design a notification service
Design a service that other teams use to send push notifications, SMS and emails to users, reliably and at high volume.
Practise it in the interview simulatorDraw your design on a canvas, stress test it with real traffic, and get a scored report. Or watch this answer build itself, step by step.1. Clarify the requirements
Before drawing anything, ask questions. These are the answers an interviewer would typically give:
- Which channels?
- iOS push, Android push, SMS and email.
- Volume?
- 10 million push, 1 million SMS and 5 million emails per day.
- Real time?
- Soft real time: a slight delay under load is OK.
- Opt-out?
- Users can opt out per channel.
- Duplicates?
- Avoid sending the same notification twice; never lose one.
2. Estimate the scale
Assumptions: 10M push + 1M SMS + 5M email per day.
- Average notifications per second (all channels): about 185 per second16M ÷ 86,400 ≈ 185/s (spiky: marketing blasts can be 100× that).
3. The high-level design
- Services call one notification APIBilling, shipping and social features don't talk to Apple or SendGrid themselves: they call a notification service behind a load balancer.
- Users, devices and settingsTo send anything you need device tokens, emails and phone numbers, plus each user's opt-outs. Cache them: they're read for every notification.
- One queue per channelEach channel gets its own queue and workers, so a slow email provider can't delay push notifications. Workers retry with backoff.
- Third-party providers deliverWorkers hand messages to APNs/FCM and an email provider, and log every send so retries never duplicate a message.
- Watch it in productionMetrics and alerts close the loop: queue depth per channel, provider error rates and delivery latency.
4. The components and what each one does
- Services that notify Client (web)
- Billing, shipping, social… call POST /v1/notify.
- Load balancer Load balancer
- Spreads requests over the stateless servers behind it, health-checks them and routes around a dead one. Rate limits abusive clients.
- Notification servers App servers
- Validate the request, check the user's settings and opt-outs, rate limit, then queue one job per channel. Stateless; authenticated callers only.
- Settings cache Cache
- User settings and device tokens.
- Users, devices & settings SQL database
- Device tokens, emails, phones, opt-outs. Sharded by user ID; primary + replicas with failover.
- Push workers Workers
- Send, retry with exponential backoff, dedupe by notification ID.
- Email workers Workers
- Send, retry with exponential backoff, dedupe by notification ID.
- APNs / FCM 3rd-party service
- Push notification delivery to iOS and Android.
- Email provider 3rd-party service
- SendGrid / SES.
- Notification log NoSQL / KV store
- Every send and its status, keyed by notification ID (partitioned by it): retries are idempotent.
- Metrics & alerts Metrics & alerts
- Dashboards and alerts on p99 latency, error rate, queue depth and cache hit ratio, so a bottleneck shows up before it becomes an outage.
5. Deep dive: reliable delivery
How do you make delivery reliable with flaky third-party providers? How do you avoid duplicates, respect opt-outs and limit spam?
- One queue per channel, so a broken provider doesn't block others.
- Persist notifications in a log/DB; retry failures with backoff; dedup by event ID.
- Check user settings before sending and rate-limit per user.
6. What interviewers listen for
- Send API for internal servicesServices call one API with user IDs, channel and template parameters.
- One queue per channelA failing SMS provider shouldn't delay iOS pushes.
- Retries with backoffProviders fail transiently; retry and alert on persistent failures.
- Deduplication / idempotencyAt-least-once delivery means dupes; check event IDs before sending.
- TemplatesReusable templates keep notifications consistent.
- Delivery tracking & analyticsTrack sent/delivered/opened to monitor health and engagement.
- Database replication and failoverA single database is a single point of failure. Replicas give redundancy and read capacity; failover promotes a replica when the primary dies.
- Partition (shard) data as it growsOne machine eventually can't hold the data or the write load. Say how you'd split it and by which key.
7. Follow-up questions
- Your SMS provider is down for 30 minutes. What happens to SMS and to the other channels?
- Marketing sends a campaign to 50 million users at 9:00. How does your system cope?
Answer them in the simulator
The key points for each follow-up, your scored report and the stress test are part of Pro: ₹299 a month or ₹1,999 a year.
See ProThe design in a nutshell
- Services → notification servers (auth, validation, settings check, templates) → one queue per channel → workers → APNs/FCM/SMS/email providers.
- Notification log in a DB for retries; dedup by event ID; retries with backoff and alerts.
- Per-user rate limits and opt-out settings; tracking of delivery events; monitoring queue depth.
Related lessons: Improved design: queues per channel · Reliability: no data loss, no duplicates · Templates, settings, security, tracking, and the final design