Design a large-scale Notification Platform

Question

Design a event-driven notification system that handles millions of requests. Discuss trade-offs in consistency, availability, and performance.

Codemia · Accepted Answer

### Functional Requirements
1. **Notification Types**: Support various types of notifications including trades, account alerts, promotions, and system messages.
2. **Delivery Mechanisms**: Support delivery via push notifications, SMS, and email.
3. **User Preferences**: Allow users to set preferences for notification types and delivery methods.
4. **Event-driven Architecture**: Handle incoming events that trigger notifications in real-time.
5. **Rate Limiting**: Implement rate limiting to prevent spamming users with notifications.

### Non-Functional Requirements
1. **Scalability**: The system must handle millions of notifications per day with the ability to scale horizontally.
2. **Availability**: Aim for 99.9% uptime to ensure users receive timely notifications.
3. **Latency**: Notifications should be sent within seconds of the triggering event.
4. **Security**: Ensure secure transmission of sensitive data and user preferences.
5. **Monitoring & Logging**: Implement comprehensive monitoring and logging to track delivery success rates and user engagement.

Assuming Robinhood has approximately 10 million active users:
- **Notification Frequency**: If we estimate that each user receives about 2 notifications per day, that results in **20 million notifications per day**.
- **Peak Load**: During peak trading hours, we can assume a 3x increase in notifications, leading to approximately **60 million notifications**.
- **Throughput**: To handle this load, we can assume we need to process around **1,000 notifications per second** (60 million / 60 seconds).
- **Storage**: If we store notifications for 30 days for auditing, we would need to store about **600 million notification records**.

The architecture consists of:
1. **Event Producer**: A microservice that emits events (e.g., trade completion) to a message queue.
2. **Message Queue**: Use **Kafka** for handling high-throughput, durable message storage and delivery.
3. **Notification Service**: A microservice that consumes events from Kafka and dispatches notifications based on user preferences.
4. **User Preference Storage**: A **NoSQL database** (e.g., MongoDB) for storing user notification preferences and settings.
5. **Delivery Mechanism**: Utilize third-party services for SMS (Twilio) and email (SendGrid) notifications, along with in-app push notifications.
6. **Monitoring & Logging**: Implement **Prometheus** for monitoring and **ELK Stack (Elasticsearch, Logstash, Kibana)** for logging and visualization.

### User Preferences Schema (MongoDB)
```json
{
  "userId": "string",
  "preferences": {
    "email": { "enabled": true, "frequency": "daily" },
    "sms": { "enabled": false },
    "push": { "enabled": true }
  }
}
```  
### Notification Schema
```json
{
  "notificationId": "string",
  "userId": "string",
  "type": "string",
  "message": "string",
  "timestamp": "datetime",
  "status": "sent|failed"
}
```  
This design supports efficient querying based on userId and notification type, essential for delivering personalized notifications.

1. **Consistency vs. Availability**: Given the event-driven nature of the system, eventual consistency is acceptable for notification delivery. Users may receive notifications slightly out of order but will not miss them.
2. **Database Choice**: Choosing a NoSQL database allows for horizontal scaling and flexibility in changing user preferences but may sacrifice complex querying capabilities compared to a relational database.
3. **Rate Limiting**: Implementing strict rate limiting could impact user experience by delaying notifications during peak times, so a balance must be struck to ensure timely delivery without overwhelming the user.
4. **Monitoring Complexity**: Introducing multiple components (Kafka, NoSQL, external services) increases the complexity of monitoring and debugging, necessitating robust observability tools to track each part effectively.

Design a large-scale Notification Platform

Robinhood

What the Interviewer Expects

Key Topics to Cover

How to Approach This

Possible Follow-up Questions

Practice a Similar Problem on Codemia

Sample Answer

Requirements

Functional Requirements

Capacity Estimation

Submit Your Answer

Robinhood 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