System Design Interview Question: Design a Notification System

A
Author
01 May, 2026 1 min read 962 views

A popular question that combines APIs, queues, third-party integrations and reliability.

Requirements

  • Channels: mobile push, email, SMS, in-app.
  • Triggered by other services ("order shipped") and by scheduled campaigns.
  • Respect user preferences and quiet hours; no duplicates.
  • Scale: millions of notifications per day, with bursts during campaigns.
  • Soft real-time: transactional messages within seconds; marketing can be slower.

Architecture

Services --> [Notification API] --> validate, dedupe, check preferences
                                 --> [Queue per channel + priority]
                                        |        |        |
                                 [Push workers][Email][SMS workers]
                                        |        |        |
                                      APNs/FCM  Email   SMS provider
                                               provider
             [Notification log DB] <-- status updates, delivery receipts

Key components

  • Notification API: accepts { userId, type, data, idempotencyKey }; returns immediately.
  • Preferences service: per-user, per-type, per-channel opt-ins, quiet hours and locale.
  • Templates: stored and versioned per type, channel and language; rendered by workers.
  • Separate queues per channel and priority, so a marketing blast doesn't delay password-reset emails.
  • Workers call providers, retry with backoff on transient failures, and move permanent failures to a dead-letter queue.

Reliability details

  • Idempotency keys to avoid double sends on retries.
  • Rate limits per user (don't spam) and per provider (respect their quotas).
  • Fallbacks: if push fails or the device token is invalid, consider email; clean up stale device tokens.
  • Provider failover: a second email/SMS provider for critical messages.

Tracking

Store each notification's status (queued, sent, delivered, opened, failed) from provider callbacks. This powers debugging ("why didn't I get the OTP?"), analytics and the in-app notification inbox.

Was this article helpful?

Comments

No comments yet. Have a question or a tip? Be the first to share it.

Leave a comment

Comments are reviewed before they appear.