Katkat
Back

Design a Scalable Notification System

J.P. MorganSoftware Engineer · Onsite
MediumSoftware EngineerOnsiteSystem Design

Last updated

This question assesses the ability to design a distributed, asynchronous notification system capable of handling high-throughput multi-channel messaging while maintaining strict delivery guarantees and rate-limiting policies.

Design a Scalable Notification System

Design a notification service that sends alerts to users across three channels: push notifications, email, and SMS. The system must support millions of users and high burst traffic (e.g., flash sales or market volatility alerts).

Functional Requirements

  • Support multiple channels: Push, Email, SMS.
  • Allow users to subscribe/unsubscribe from specific notification types.
  • Notifications should be queued to handle traffic spikes.

Non-Functional Requirements

  • Scalability: Handle high volume during peak times.
  • Reliability: Ensure "at-least-once" delivery for critical alerts.
  • Latency: Minimize end-to-end delivery time, though asynchronous processing is acceptable.
  • Rate Limiting: Prevent spamming users (e.g., max 5 SMS per hour per user).

Your Task

Provide a high-level system design including:

  1. API Design: Define the interface for service clients to trigger notifications.
  2. Data Model: Briefly describe the schema for storing user preferences and message status.
  3. Architecture: Describe the flow of a notification from the client request to the final delivery to a third-party gateway (e.g., Twilio for SMS, APNS for Push).
  4. Handling Failures: How do you manage retries if a third-party provider is down?

Constraints

  • Assume 100,000 notifications per second during peak.
  • You must account for multi-tenancy and different delivery priorities.

Hints

Hint 1

Consider using a message queue like Kafka to decouple the ingestion service from the delivery workers.

Hint 2

Think about how to implement a distributed rate-limiter using a cache like Redis to track user-level thresholds across multiple service nodes.

Hint 3

Address reliability by implementing a persistent storage layer for audit logs and a dead-letter queue for notifications that failed after several retries.

Follow-up questions

  • How would you handle notifications that need to be delivered in a specific order for the same user?
  • If a third-party provider experiences significant latency, how would you design a circuit breaker to prevent your entire system from backing up?
  • How would you modify the system to handle 'preference centers' where users can customize notification frequency and silence periods?