Design a Notification System

Question

Design a scalable notification system supporting push notifications, email, and SMS channels. Cover event-driven architecture, message bus design, user preference management, rate limiting, and delivery guarantees at Meta's scale.

Codemia · Accepted Answer

- **Functional Requirements:**  
  1. Support multiple notification channels: push notifications, email, and SMS.  
  2. User preference management to allow users to opt-in/out of specific channels.  
  3. Real-time delivery of notifications with confirmation receipts for successful deliveries.  
  4. Rate limiting to prevent spamming of users.  
  5. Ability to handle scheduled notifications and recurring notifications.  
  
- **Non-Functional Requirements:**  
  1. Scalability to handle billions of notifications per day.  
  2. High availability with a target uptime of 99.99%.  
  3. Low latency for push notifications (<100ms) and emails/SMS (<1 second).  
  4. Data privacy and security compliance with GDPR and CCPA.  
  5. Observability with detailed logging and monitoring for troubleshooting.

- **User Base:** Assume Meta has 2 billion active users.  
  - **Notification Frequency:** Assume an average of 3 notifications/user/day.  
  - **Total Notifications:**  
    - Daily: 2 billion users * 3 notifications = 6 billion notifications/day.  
    - Peak Load: Assume peak times can handle 10% of daily volume in 1 hour = 600 million/hour or ~166.67 million/minute.  
  
- **Channel Distribution Assumption:**  
  - 60% push, 30% email, 10% SMS.  
  
- **Capacity Requirements:**  
  - Push notifications: 360 million/hour  
  - Emails: 180 million/hour  
  - SMS: 60 million/hour  
  
- **Throughput Requirements:**  
  - This requires a distributed messaging system capable of higher throughput and parallel processing.

- **Component Diagram Overview:**  
  1. **Notification Service:** Central service handling notification logic; uses **gRPC** for communication.  
  2. **Message Bus:** **Kafka** for event streaming to decouple services.  
  3. **Delivery Services:**  Separate services for each channel (Push, Email, SMS) using **Node.js** for high concurrency.  
  4. **User Preference Store:** **Cassandra** for storing user preferences and notification settings.  
  5. **Rate Limiter:** Implemented as a microservice using **Redis** for fast access.  
  6. **Monitoring Service:** **Prometheus** and **Grafana** for real-time monitoring and alerting.  
  
- **Architecture Flow:**  
  1. Event generated by user action -> sent to Notification Service.  
  2. Notification Service pushes event to Kafka.  
  3. Delivery Services consume messages and respect user preferences and rate limits.

- **Schema Design:**  
  1. **User Table:**  
     - user_id (PK)  
     - email  
     - phone_number  
     - push_token  
     - preferences (JSON)  
     
  2. **Notification Table:**  
     - notification_id (PK)  
     - user_id (FK)  
     - channel (ENUM: push, email, SMS)  
     - content (JSON)  
     - status (ENUM: pending, sent, failed)  
     - created_at  
     
  3. **Rate Limit Table:**  
     - user_id (PK)  
     - count  
     - window_start  
     
- **Access Patterns:**  
  - Frequent reads for user preferences.  
  - Writes for notifications and updates on delivery status.

- **Trade-offs Considered:**  
  1. **Eventual Consistency vs. Strong Consistency:**  
     - Chose eventual consistency for notifications to allow for high throughput and lower latency; acceptable in the context of notifications.  
  2. **Centralized vs. Decentralized Notification Handling:**  
     - Decentralized approach using services for each channel improves scalability but adds complexity in managing user preferences across channels.  
  3. **Using Kafka vs. RabbitMQ:**  
     - Chose Kafka for its high throughput and durability, capable of handling large volumes of messages which is critical for Meta's scale.  
  4. **Rate Limiting Granularity:**  
     - Implemented user-level rate limiting to prevent abuse; could consider application-level if required for broader restrictions.  
  5. **Data Storage Choices:**  
     - Chose Cassandra for scalability but may introduce complexity in querying; trade-off between read/write speed and query capabilities.

Design a Notification System

Meta

How to Approach This

Sharpen Your Skills on Codemia

Sample Answer

Requirements

Capacity Estimation

Submit Your Answer

Meta Software Engineer Interview Guide

Related Questions

Design a high-throughput Inventory Management System

Design a low-latency Rate Limiting System

Design a fault-tolerant Payment System

Design a fault-tolerant Messaging System

Design Walmart Product Search