Design a Notification System
Related Concepts: Message Queues (Kafka/SQS), Fan-Out Pattern, Push Services (APNs/FCM), Rate Limiting, Template Engine, User Preferences, Retry with Backoff, Idempotency, Dead Letter Queue
Design a system that sends notifications to users via multiple channels: push notifications, SMS, and email.
- Support multiple channels: push (iOS/Android), SMS, email
- Soft real-time delivery (slight delays acceptable)
- Users can configure notification preferences
- Support scheduled notifications
- Rate limiting to prevent notification spam
- Template-based content management
| Requirement | Target | Rationale |
|---|
| Availability | 99.99% | Critical alerts must always work |
| Scalability | 1B notifications/day | Handle viral events, marketing blasts |
| Latency | < 30 seconds p99 | User expects timely notifications |
| Delivery | At-least-once | Better to duplicate than miss |
| Reliability | Handle provider failures | No single point of failure |
- 100 million users
- 1 billion notifications/day (~12K/second average)
- Peak: 10x average (during events)
- Storage: 1B x 1KB = 1TB/day for notification logs
| Channel | Provider | Cost | Reach | Latency | Content |
|---|
| iOS Push | APNs | Free | Requires app | Sub-second | 4KB payload |
| Android Push | FCM | Free | Requires app | Sub-second | 4KB payload |
| SMS | Twilio, Nexmo | $0.01-0.05/msg | Universal | 1-5 seconds | 160 chars |
| Email | SendGrid, SES | $0.0001/msg | Universal | Seconds-minutes | Unlimited |
| Use Case | Channel | Reason |
|---|
| OTP/Security alerts | SMS | Most reliable, no app needed |
| Time-sensitive alerts | Push | Instant, free |
| Marketing campaigns | Email | Rich content, cost-effective |
| Critical transactions | Push + SMS fallback | Redundancy |
Loading diagram...
Loading diagram...
| Setting | Options | Default | Purpose |
|---|
| Channel enabled | true/false per channel | All enabled | Opt-out control |
| Quiet hours | Start/end time | None | No notifications during sleep |
| Timezone | IANA timezone | UTC | Respect local time |
| Frequency cap | Max per day/hour | Unlimited | Prevent spam |
| Priority threshold | Critical/High/Normal/Low | Low | Only receive above threshold |
| Category | Default Channel | User Configurable |
|---|
| Security (OTP, alerts) | SMS + Push | Channel only |
| Transactions | Push + Email | Yes |
| Social (likes, comments) | Push | Yes |
| Marketing | Email | Yes |
| Reminders | Push | Yes |
Loading diagram...
| Field | Type | Purpose |
|---|
token_id | UUID | Primary key |
user_id | BIGINT | Owner |
device_token | VARCHAR(255) | Provider-specific token |
platform | ENUM(ios, android) | Determines provider |
app_version | VARCHAR(20) | For feature flags |
created_at | TIMESTAMP | For cleanup |
last_used_at | TIMESTAMP | Activity tracking |
| Provider Response | Action | Reason |
|---|
| Success | Update last_used_at | Token is valid |
| Invalid token | Delete immediately | Token no longer valid |
| Unregistered | Delete immediately | App uninstalled |
| Rate limited | Retry with backoff | Provider overloaded |
| Server error | Retry with backoff | Temporary issue |
Loading diagram...
| Level | Push | SMS | Email | Reason |
|---|
| Per user/hour | 10 | 5 | 20 | Prevent spam |
| Per user/day | 50 | 10 | 100 | Daily cap |
| Marketing/day | 1 | 0 | 3 | User experience |
| Provider/second | N/A | 100 | 1000 | API limits |
| Failure Type | Strategy | Max Retries | Backoff |
|---|
| Network timeout | Immediate retry | 3 | None |
| Provider 5xx | Exponential backoff | 5 | 1s, 2s, 4s, 8s, 16s |
| Rate limited | Fixed delay | 10 | Provider's retry-after |
| Invalid token | No retry | 0 | Delete token |
Loading diagram...
| Scenario | Without Idempotency | With Idempotency |
|---|
| Network retry | User gets duplicate | Only one delivered |
| Worker crash | May resend | Safe to replay |
| Queue replay | Duplicate notifications | Deduplicated |
Implementation: Store notification_id in Redis with TTL; skip if already processed.
Loading diagram...
| Priority | Max Latency | Use Cases |
|---|
| P1 Critical | 5 seconds | OTP, fraud alerts, password reset |
| P2 High | 30 seconds | Order confirmation, payment receipt |
| P3 Normal | 5 minutes | Likes, comments, follows |
| P4 Low | 30 minutes | Marketing, weekly digest |
Loading diagram...
| Metric | Target | Alert Threshold |
|---|
| Delivery rate | > 95% | < 90% |
| P99 latency | < 30s | > 60s |
| Provider error rate | < 1% | > 5% |
| Invalid token rate | < 5% | > 10% |
| Queue depth | < 100K | > 500K |
| Rate limit hits | < 1% | > 5% |
| Component | Push | SMS | Email |
|---|
| Title | Yes (50 chars) | No | Yes (subject) |
| Body | Yes (200 chars) | Yes (160 chars) | Yes (HTML) |
| Rich content | Image, action buttons | No | Images, links, formatting |
| Personalization | Yes | Yes | Yes |
| Field | Storage | Fallback |
|---|
| Template ID | order_shipped | - |
| Language | User preference | en-US |
| Variables | {order_id}, {name} | Required |
| Company | Scale | Notable Features |
|---|
| Twilio Notify | Millions/day | Multi-channel API, delivery receipts |
| Firebase | Billions/day | Free push, topic subscriptions |
| Amazon SNS | Billions/day | AWS integration, fanout patterns |
| OneSignal | 10B+/day | Segmentation, A/B testing |
| Airship | Enterprise | ML-based send time optimization |
| Decision | Options | Recommendation |
|---|
| Delivery guarantee | At-most-once, At-least-once | At-least-once with idempotency |
| Queue architecture | Single queue, Per-channel, Per-priority | Per-channel with priority levels |
| Provider strategy | Single provider, Multi with failover | Multi-provider with automatic failover |
| Rate limiting | User-level, Global, Both | Multi-level (user + category + provider) |
| Token storage | In-memory, Database | Database with caching |
| Logging | All notifications, Failures only | All notifications for audit trail |