Skip to main content
Designing a notification system is a common interview question because it surfaces many reusable system‑design patterns: scalability, delivery guarantees, latency trade‑offs, and user preferences. At a high level, the system must detect product events (for example, a successful payment or a reply to your comment) and deliver the right message to the right user over the right channels—even when the user is not actively using the app. Common delivery channels:
  • push (mobile push notifications)
  • sms
  • email
  • in-app indicators (badges, dots, or an activity feed)
In short: accept an event, determine recipients and channels, respect preferences, and deliver reliably with appropriate latency.
A simple diagram of a notification workflow: an event is sent to a notification system which then delivers messages via push, SMS, email, or in‑app. On the right a phone shows those notifications being delivered to "the right user."
When asked to design this system, start by clarifying requirements. Ask focused questions to extract both functional and non‑functional constraints. Below are four high‑value clarifying questions and why they matter.
  1. What are these notifications for?
    Distinguish the notification classes:
    • Transactional: time‑sensitive messages—payment receipts, OTPs, shipping updates. Latency and reliability are critical.
    • Marketing: promotional content—newsletters, flash sales. Can tolerate higher latency and different delivery policies.
    If both are required, the system should be able to satisfy low‑latency transactional needs while scaling to high‑volume marketing campaigns.
  2. Which channels must be supported?
    Confirm supported channels and whether any channel has special constraints (third‑party quotas, cost per message, or legal requirements for SMS/email).
  3. Do transactional and marketing notifications need the same latency?
    Understand patience levels. Transactional messages often must reach users within seconds; marketing can be queued for batch delivery. This affects architecture choices (sync vs async paths, priority queues, reserved capacity).
A dark-themed infographic showing two patience levels—short "seconds" for transactional messages and longer "minutes" for marketing—using progress bars, a sample login code, and a flash-sale icon. It also includes stick-figure users labeled "Alan"/"Interviewer"/"You" and a notes column on the right.
  1. Can we lose a notification? Can duplicates occur?
    Clarify durability and idempotency constraints:
    • Is best‑effort acceptable or must we strive to never lose messages?
    • Are duplicate deliveries tolerable, or is exactly‑once required?
    • Do users have opt‑out preferences (e.g., marketing opt‑out), and are there regulatory constraints in certain jurisdictions?
These answers drive design decisions around retries, persistence, deduplication, and per‑user preference enforcement.
A dark-themed UI mockup showing a "Notifications" panel with toggle switches for Marketing (off) and Payments (on) next to a box labeled "In some countries, the law," and a stick-figure labeled Alan on the left. A notes column on the right lists numbered points, and a small chat bubble at the bottom shows an interviewer saying marketing can be switched off.
Define the scope clearly before designing. Below is a concise capture of common functional and non‑functional requirements.
A dark-themed slide showing two main boxes: "Functional — What it must do" (one event in, four channels out, respect preferences) and "Non-functional — How well" (small delay okay, try not to lose one, ideally never twice). A notes column on the right lists five numbered points and small avatars labeled "Interviewer" and "You" appear at the bottom.
Practical design guidance (interview-friendly checklist)
  • Use separate paths for transactional vs marketing traffic: priority queues and reserved capacity for transactional messages; batch or rate‑limited workers for marketing.
  • Persist messages (write‑ahead log or durable queue) to avoid loss. Use retries with exponential backoff for transient failures.
  • Aim for at‑least‑once delivery and implement idempotency or deduplication at the consumer side (or include a unique notification_id with each send).
  • Enforce user preferences early (filter before sending to external providers) to avoid wasted cost and regulatory issues.
  • Monitor third‑party channel health and quota limits (SMS gateways, push providers). Provide fallback behavior if a channel fails.
  • Auditability: store delivery status and logs for troubleshooting and compliance.
Exactly‑once delivery is extremely difficult to guarantee in distributed systems. Aim for reliable (at‑least‑once) delivery combined with deduplication and idempotency, and prioritize transactional messages for low latency.
Links and references Use this structure when answering in an interview: clarify scope with the four questions, state functional/non‑functional requirements, sketch a high‑level architecture that separates low‑latency vs high‑throughput paths, and highlight delivery/duplication trade‑offs.

Watch Video