DEV Community

Gregory Chris
Gregory Chris

Posted on

Designing a Notification System: Push, Email, and SMS at Scale

#systemdesign #notifications #messaging #interview

Designing a Notification System: Push, Email, and SMS at Scale

Building a scalable, unified notification system is a quintessential challenge in distributed systems design. From delivering billions of notifications daily to ensuring timely, reliable, and user-friendly communication, this system must handle immense complexity. Whether it's a push notification for a breaking news update, a promotional email, or an SMS alert for suspicious account activity, designing such a system requires careful thought about architecture, trade-offs, and scalability.

In this post, we’ll dive deep into the architecture of a notification system, focusing on how to deliver messages across multiple channels (push, email, SMS) at scale. We'll explore queuing, delivery guarantees, user preferences, and strategies to avoid notification fatigue. By the end of this post, you’ll have a solid strategy for discussing this topic in system design interviews and applying the principles in real-world scenarios.

Table of Contents

  1. The Problem Statement
  2. Key Requirements
  3. High-Level System Architecture
  4. Core Design Considerations
  5. Scaling the System
  6. Common Interview Pitfalls
  7. Talking Points and Frameworks
  8. Key Takeaways and Next Steps

The Problem Statement

Imagine you’re designing a notification system for a company like Uber or Twitter. The system must:

  • Deliver billions of notifications daily across push, email, and SMS channels.
  • Respect user preferences (e.g., “no promotional SMS after 9 PM”).
  • Ensure reliable delivery of critical notifications.
  • Prevent notification fatigue by intelligently throttling or aggregating notifications.
  • Scale seamlessly as user demand grows.

This system must balance real-time delivery with cost-effectiveness, system reliability, and user experience.

Key Requirements

Before diving into the architecture, let's define the core functional and non-functional requirements.

Functional Requirements:

  1. Multi-channel support: Push notifications, emails, and SMS.
  2. User preferences management: Allow users to opt-in or out of certain notification types or channels.
  3. Prioritization: Critical notifications (e.g., password reset emails) must take precedence over non-critical ones.
  4. De-duplication: Avoid sending redundant notifications.
  5. Rate limiting: Prevent spamming users with excessive notifications.
  6. Intelligent batching: Group related notifications when appropriate (e.g., a daily digest email).

Non-Functional Requirements:

  1. Scalability: Handle billions of notifications daily without performance degradation.
  2. Reliability: Ensure at-least-once delivery for critical messages.
  3. Latency: Minimize delivery delays for time-sensitive notifications.
  4. Cost-efficiency: Optimize for cost, especially for expensive channels like SMS.

High-Level System Architecture

Let’s start with a high-level architecture diagram:

                    ┌───────────────┐
                    │ Notification  │
  ┌──────────┐      │ API Gateway   │
  │ Producers │────▶│               │
  └──────────┘      │               │
                    └───────┬───────┘
                            │
                            ▼
                     ┌─────────────┐
                     │ Message Bus │
                     └─────┬───────┘
                           │
     ┌─────────────────────┼─────────────────────┐
     ▼                     ▼                     ▼
┌────────────┐      ┌────────────┐        ┌────────────┐
│ Push Worker│      │ Email Worker│       │ SMS Worker  │
└────────────┘      └────────────┘        └────────────┘
     │                     │                     │
     ▼                     ▼                     ▼
┌────────────┐      ┌────────────┐        ┌────────────┐
│ Push Server│      │ Email Server│       │ SMS Gateway │
└────────────┘      └────────────┘        └────────────┘
Enter fullscreen mode Exit fullscreen mode

Components:

  1. Producers: Services or users that generate notifications (e.g., a ridesharing app generating trip updates).
  2. Notification API Gateway: Accepts notification requests and validates them.
  3. Message Bus: A distributed system (e.g., Kafka) that queues notifications for processing.
  4. Workers: Dedicated workers for each channel (push, email, SMS) that process and send notifications.
  5. Delivery Systems: External systems or APIs that perform the final delivery (e.g., Firebase for push, Twilio for SMS).

Core Design Considerations

1. Multi-Channel Delivery

Each channel has unique characteristics:

  • Push Notifications: Instant, low-cost, but dependent on app installation and device connectivity.
  • Email: Reliable, supports rich formatting, but slower and more likely to be ignored.
  • SMS: High open rates, great for critical alerts, but expensive.

Trade-Offs:

  • Use push for real-time updates and notifications requiring immediate action.
  • Reserve SMS for critical messages (e.g., OTPs) due to cost.
  • Use email for long-form content or non-urgent updates.

2. Message Queuing

A message queue (e.g., Kafka, RabbitMQ) is essential for decoupling producers from consumers. This ensures:

  • Scalability: Producers don’t overwhelm workers.
  • Durability: Messages persist even if the system crashes.

Example: Twitter uses Kafka for its notification system to handle millions of messages per second.

3. Delivery Guarantees

Notification systems typically require at-least-once delivery for critical messages. To achieve this:

  • Store messages in a durable queue.
  • Use idempotent operations to prevent duplicates.

For less critical messages, best-effort delivery may suffice to reduce system load.

4. User Preferences

Users should control how and when they receive notifications. Store preferences in a User Preferences Service:

  • Preferred channels (e.g., push only).
  • Quiet hours (e.g., no messages after 10 PM).

5. Avoiding Notification Fatigue

Notification fatigue can lead to user churn. Mitigation strategies:

  • Priority-based notifications: Only send high-priority notifications in real time.
  • Batching: Group multiple notifications into a single message (e.g., daily digest emails).
  • Personalization: Tailor notifications to user behavior and preferences.

6. Intelligent Batching and Rate Limiting

Batching reduces system load and improves user experience:

  • Aggregate notifications over a configurable time window (e.g., collect all updates in the past hour).

Rate limiting ensures users aren’t overwhelmed:

  • Limit notifications per user per channel (e.g., “no more than 5 SMS per day”).

Scaling the System

Scaling strategies include:

  1. Sharding: Partition users across shards to distribute load.
  2. Horizontal Scaling: Add more workers and servers as demand grows.
  3. Caching: Use distributed caches (e.g., Redis) for frequently accessed data like user preferences.

Common Interview Pitfalls

  1. Overengineering: Avoid proposing overly complex solutions for small-scale systems.
  2. Ignoring Trade-Offs: Always discuss cost, latency, and reliability trade-offs.
  3. Forgetting Edge Cases: Consider scenarios like system failures, retry storms, or duplicate notifications.

Talking Points and Frameworks

Framework: "5 Steps to System Design"

  1. Clarify requirements.
  2. Define high-level architecture.
  3. Address core components and trade-offs.
  4. Plan for scaling.
  5. Estimate bottlenecks and mitigations.

Key Interview Points:

  • Discuss channel trade-offs (push vs. email vs. SMS).
  • Highlight user preferences and personalization.
  • Emphasize reliability (e.g., durable queues, retries).

Key Takeaways and Next Steps

Key Takeaways:

  • A notification system must balance scalability, reliability, and user experience.
  • Consider trade-offs for each channel and align them with use cases.
  • Mitigate notification fatigue through personalization, batching, and rate limiting.

Next Steps:

  1. Practice designing smaller subsystems (e.g., a push notification service).
  2. Study real-world examples like Uber’s messaging system or LinkedIn’s InMail service.
  3. Prepare to articulate trade-offs and scaling challenges in interviews.

Designing a notification system is an excellent way to showcase your distributed systems expertise. Mastering this topic will not only prepare you for interviews but also give you insights into building scalable systems in the real world. Ready to dive deeper? Start sketching your architecture and refining your approach today!

Top comments (0)