Notification System
Problem
Design a scalable notification system that sends push, email, and SMS notifications to millions of users.
Functional Requirements
- Support push (mobile), email, SMS channels
- Send notifications based on events (order placed, message received)
- User preferences — opt-out, quiet hours, channel preference
Non-Functional Requirements
- High availability — notification must not be lost
- At-least-once delivery (idempotent consumers)
- Low latency for push, best-effort for email
High-Level Design
Event Source → Message Queue (Kafka/SQS) → Notification Workers → Channel Providers
↓
Push: FCM/APNs
Email: SendGrid
SMS: Twilio
Key Components
- Event producers — user actions, backend services publish events
- Message queue — Kafka for durability + fan-out; SQS for simplicity
- Notification service — consumes events, resolves user preferences, routes to channel
- Channel providers — 3rd party (FCM, SendGrid, Twilio)
- Template service — localisation, personalisation
- User preference DB — per-user opt-outs, channel settings
Key Tradeoffs
| Decision | Consideration |
|---|---|
| Push vs Pull | Push from service; pull for digest/batching |
| Kafka vs SQS | Kafka → fan-out to multiple consumers; SQS → simpler |
| Retry logic | Exponential backoff + dead letter queue |
| Idempotency | Dedup on notification ID before send |