· SWE Editorial · System Design · 5 min read
Design a Notification System: System Design Interview Guide
A structured framework for answering the notification system design interview question, covering push/email/SMS channels, priority queues, rate limiting, template engines, and delivery tracking.
“Design a notification system” looks deceptively simple — send a message to a user — but the interview signal comes from how you handle multiple channels, prioritization under load, and reliable delivery tracking at scale. Weak answers describe a single queue that fans out to push/email/SMS with no thought to failure isolation or rate limiting. Strong answers treat each channel as its own subsystem with its own failure modes. This guide gives you a framework for answering the question the way a senior interview loop expects.
Core Concepts
| Concept | What it means | Why it matters in interviews |
|---|---|---|
| Push/email/SMS channels | The distinct delivery mechanisms a notification system must support, each with different providers, latency, and cost | Interviewers want to see you treat each channel as independently pluggable, not a single monolithic “send” function |
| Priority queue | Ordering notification delivery so time-sensitive messages (e.g., security alerts) are processed before low-priority ones (e.g., marketing digests) | Tests whether you can design for graceful degradation under load rather than uniform best-effort delivery |
| Rate limiting | Capping the volume of notifications sent to a single user (and to third-party providers) within a time window | A frequent follow-up: “how do you prevent notification spam?” |
| Template engine | A system for rendering notification content from a template plus variable data, per channel and per locale | Shows you understand content and delivery are separate concerns |
| Delivery tracking | Recording sent/delivered/failed/opened state per notification per channel | The mechanism that makes retries, analytics, and debugging possible |
Interview Answer Framework
Structure your answer through these four steps:
- Clarify channels, volume, and priority tiers. Ask which channels are in scope (push, email, SMS, in-app), expected daily notification volume, and whether there are distinct priority tiers (e.g., security alerts vs. marketing). State assumptions explicitly — this shapes whether you need a single shared pipeline or channel-specific pipelines with different SLAs.
- Design the ingestion and prioritization layer. Describe a notification service that accepts requests from upstream services (order confirmations, security events, marketing campaigns), validates and enriches them, then places them onto a priority queue — typically implemented as multiple queues by priority tier (high/medium/low) with weighted consumption so high-priority notifications aren’t starved but low-priority volume doesn’t get dropped entirely.
- Design per-channel delivery workers with rate limiting. Explain that each channel (push, email, SMS) has its own worker pool consuming from the queue, since each talks to a different third-party provider (APNs/FCM for push, an ESP for email, a carrier gateway for SMS) with different rate limits and failure modes. Rate limiting happens at two levels: per-user (don’t send more than N notifications per hour to one person) and per-provider (respect the third-party API’s throughput limits, using a token bucket or similar). Isolating channels means an SMS provider outage doesn’t block push or email delivery.
- Handle templating and delivery tracking. Describe a template engine that separates notification content (a template with variable placeholders, versioned and localized) from the triggering event data, so product teams can update copy without a code deploy. For delivery tracking, describe a status table keyed by notification ID recording sent/delivered/failed/opened timestamps per channel, fed by provider webhooks (delivery receipts, bounce/open callbacks), which both drives retry logic for failures and feeds analytics dashboards.
Common Follow-ups
Expect: “How do you avoid sending duplicate notifications if a worker crashes mid-delivery?” (answer: use idempotency keys per notification-channel pair so a retried delivery attempt is a no-op if it already succeeded), “How would you let users control notification preferences per channel?” (answer: check a preference service before enqueueing, filtering out channels the user has opted out of, and treat this as a gate at ingestion time rather than at delivery time to avoid wasted work), and “What happens if the email provider is down for an hour?” (answer: the channel-specific worker pool backs off and retries with exponential backoff while the queue buffers, and other channels continue delivering unaffected since they’re isolated).
Production Considerations
In production, the biggest failure mode is treating all notifications as equal priority under load — when the queue backs up during a traffic spike, systems without tiered priority end up delaying security alerts behind marketing blasts, which is a real user-trust problem. Rate limiting needs to be enforced both to protect users from notification fatigue and to protect your own account standing with third-party providers, since exceeding a provider’s rate limit can get your sending account throttled or banned. Delivery tracking data also needs a retention and query strategy — high-volume systems generate enormous tracking record volume, so most production systems roll up detailed per-notification tracking into aggregated metrics after a short retention window rather than keeping full detail indefinitely. Finally, template versioning matters: once a notification is sent, its content should be reproducible for debugging even if the template has since been edited, so store a reference to the exact template version used, not just the template ID.
FAQ
Should I mention a specific message queue technology like Kafka or SQS? Naming one is fine, but the interviewer cares more about whether you understand why you need priority-aware queuing and per-channel isolation than which specific product you pick.
How do I handle a user who wants a digest instead of real-time notifications? Mention it as an extension: batch low-priority notifications into a scheduled digest job that aggregates and sends once per day/week, while high-priority notifications always bypass batching and go out immediately.
What’s the most common mistake candidates make on this question? Designing a single unified pipeline with no priority tiers or channel isolation, which collapses under load and lets one slow provider block delivery for every other channel.
The most comprehensive preparation system we have reviewed for this topic is The 0-to-1 SWE Interview Playbook (Amazon: https://www.amazon.com/dp/B0H256Z1MF?tag=sirjohnnymai-20).