System Design Interview Question: Design a Notification System
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.