Design a Scalable Notification System
Design a notification service that other internal teams can use to deliver messages to users across multiple channels: push notifications (mobile/web), email, and SMS. A team should be able to send a notification with a single API call (e.g., "order shipped," "password reset code," "weekly digest"), and the system should reliably fan it out to the right channel(s).
The design should address scalability, reliability, rate limiting, and the role of message queues (e.g., Kafka, RabbitMQ).
Constraints & Assumptions:
- This is a large-scale internal platform, handling tens of millions of notifications per day with potential for bursty peaks.
- The initial design should support push, email, and SMS, but be extensible for new channels (e.g., WhatsApp, in-app inbox).
- External delivery providers (APNs/FCM, email providers, SMS providers) have their own rate limits and can experience occasional outages.
- The system must differentiate between high-priority transactional notifications (e.g., OTPs) and lower-priority bulk notifications (e.g., digests).
- Specific numbers for scale and latency are assumptions to be clarified with the interviewer.
Part 1: Core Architecture and Send Path
Sketch the high-level architecture and the write/send path. This includes the public API, request validation, fan-out mechanism, data model, and channel-specific adapters. Demonstrate how the design facilitates adding new channels.
Part 2: Scalability, Reliability, and Message Queues
Explain the necessity of message queues (Kafka/RabbitMQ) for scalability and reliability. Discuss their role in decoupling, buffering, scaling workers, handling retries with backoff, dead-letter queues, idempotency, and managing downstream provider issues.
Part 3: Rate Limiting
Describe the implementation of rate limiting across different layers, including protecting downstream providers, preventing user spam, and safeguarding the platform from abusive callers.
AI interview prep
Core dilemma
Balancing the need for high throughput and low latency for transactional notifications against the inherent complexities of managing multiple unreliable third-party delivery channels and varying priorities.
3 tradeoffs and 3 stress tests locked
Interview prep
Unlock the interviewer X-Ray rubric, tradeoff matrix, stress tests, clarifying questions, and key concepts.
Design a Scalable Notification System
Design a notification service that other internal teams can use to deliver messages to users across multiple channels: push notifications (mobile/web), email, and SMS. A team should be able to send a notification with a single API call (e.g., "order shipped," "password reset code," "weekly digest"), and the system should reliably fan it out to the right channel(s).
The design should address scalability, reliability, rate limiting, and the role of message queues (e.g., Kafka, RabbitMQ).
Constraints & Assumptions:
- This is a large-scale internal platform, handling tens of millions of notifications per day with potential for bursty peaks.
- The initial design should support push, email, and SMS, but be extensible for new channels (e.g., WhatsApp, in-app inbox).
- External delivery providers (APNs/FCM, email providers, SMS providers) have their own rate limits and can experience occasional outages.
- The system must differentiate between high-priority transactional notifications (e.g., OTPs) and lower-priority bulk notifications (e.g., digests).
- Specific numbers for scale and latency are assumptions to be clarified with the interviewer.
Part 1: Core Architecture and Send Path
Sketch the high-level architecture and the write/send path. This includes the public API, request validation, fan-out mechanism, data model, and channel-specific adapters. Demonstrate how the design facilitates adding new channels.
Part 2: Scalability, Reliability, and Message Queues
Explain the necessity of message queues (Kafka/RabbitMQ) for scalability and reliability. Discuss their role in decoupling, buffering, scaling workers, handling retries with backoff, dead-letter queues, idempotency, and managing downstream provider issues.
Part 3: Rate Limiting
Describe the implementation of rate limiting across different layers, including protecting downstream providers, preventing user spam, and safeguarding the platform from abusive callers.