Design a notification system in HLD - System Design Guide

Problem Statement

When a system needs to inform users about events or updates, sending notifications directly from the main application can cause delays and failures under high load. Without a dedicated notification system, messages may be lost, delayed, or overwhelm the service, leading to poor user experience and missed critical alerts.

Solution

A notification system decouples message creation from delivery by using queues and workers. It collects notification requests, stores them temporarily, and processes them asynchronously to send via multiple channels like email, SMS, or push notifications. This ensures reliable, scalable, and timely delivery without blocking the main application.

Architecture

Application

Service

→Notification

↓

This diagram shows the flow where the application service sends notification requests to a queue. Notification workers consume from the queue and send messages through external channels like email, SMS, or push notification services.

Trade-offs

✓ Pros

→

Improves system responsiveness by offloading notification sending to asynchronous workers.

→

Increases reliability with retry mechanisms and durable queues to prevent message loss.

→

Supports multiple notification channels and easy extensibility for new types.

→

Scales horizontally by adding more workers to handle increased notification volume.

✗ Cons

→

Adds architectural complexity with additional components like queues and workers.

→

Introduces eventual consistency; notifications may be delayed under heavy load.

→

Requires careful handling of failure scenarios and duplicate message prevention.

Use when your system needs to send notifications to many users or multiple channels, especially if notification volume exceeds hundreds per second or when user experience depends on timely alerts.

Avoid if your application sends very few notifications (under 10 per minute) or if immediate, synchronous notification is critical and system load is low.

Real World Examples

Uber

Uber uses a notification system to asynchronously send ride status updates and promotions via SMS and push notifications without blocking core ride matching services.

Amazon

Amazon employs notification queues to reliably send order confirmations and shipping alerts through email and SMS, ensuring messages are not lost during peak shopping times.

LinkedIn

LinkedIn uses a notification system to deliver connection requests, messages, and job alerts across multiple channels, scaling to millions of users daily.

Alternatives

Synchronous Notification

Notifications are sent immediately within the main request flow without queuing or asynchronous processing.

Use when: Choose when notification volume is very low and immediate delivery is required without added system complexity.

Push Notification Service

Uses third-party push services directly without internal queuing or worker management.

Use when: Choose when relying on external providers for notification delivery and when internal control or customization is minimal.

Summary

A notification system prevents delays and failures by decoupling message sending from the main application.

It uses queues and workers to asynchronously deliver notifications via multiple channels reliably and at scale.

This design improves user experience and system resilience but adds complexity and eventual consistency.

Practice

1. Which component in a notification system is responsible for deciding when to send a message to a user?

easy

A. Event processor

B. Notification sender

C. User preference manager

D. Message storage

Solution

1. Step 1: Understand the role of event processor

   The event processor detects events that trigger notifications, deciding when a message should be sent.

2. Step 2: Differentiate from other components

   The notification sender delivers messages, user preference manager stores user choices, and message storage keeps records.

3. Final Answer:

   Event processor -> Option A

4. Quick Check:

   Event detection = Event processor [OK]

Hint: Event timing is handled by the event processor [OK]

Common Mistakes:

• Confusing sender with event detector
• Thinking user preferences trigger events
• Assuming storage decides timing

2. Which data structure is best suited to store user notification preferences for quick lookup?

easy

A. Linked list

B. Hash map

C. Queue

D. Stack

Solution

1. Step 1: Identify quick lookup needs

   User preferences require fast access by user ID or key, so a data structure with O(1) average lookup is ideal.

2. Step 2: Match data structures to lookup speed

   Hash maps provide constant time lookup, unlike linked lists, queues, or stacks which are slower for direct access.

3. Final Answer:

   Hash map -> Option B

4. Quick Check:

   Fast key-value access = Hash map [OK]

Hint: Use hash map for fast user preference lookup [OK]

Common Mistakes:

• Choosing linked list which is slow for lookup
• Confusing queue or stack with lookup structures
• Ignoring key-based access needs

3. Consider this simplified flow: An event triggers a notification, which is stored in a queue before delivery. What happens if the queue is full?

medium

A. Queue automatically expands without limit

B. System crashes due to overflow

C. Notifications are sent immediately bypassing the queue

D. New notifications are dropped or delayed

Solution

1. Step 1: Understand queue capacity limits

   Queues have fixed or limited size; when full, they cannot accept new items immediately.

2. Step 2: Identify common handling of full queues

   Systems usually drop new notifications or delay them until space frees up; automatic unlimited expansion is rare to avoid resource exhaustion.

3. Final Answer:

   New notifications are dropped or delayed -> Option D

4. Quick Check:

   Full queue = drop or delay new notifications [OK]

Hint: Full queue means drop or delay notifications [OK]

Common Mistakes:

• Assuming infinite queue size
• Thinking notifications bypass queue
• Believing system crashes on full queue

4. A notification system sends duplicate messages to users. Which design mistake most likely causes this?

medium

A. Notifications sent synchronously

B. User preferences not stored

C. No deduplication in event processing

D. Using a single message queue

Solution

1. Step 1: Analyze duplicate message causes

   Duplicates often occur if the system processes the same event multiple times without checking if notification was already sent.

2. Step 2: Evaluate other options

   Missing user preferences or synchronous sending do not cause duplicates; a single queue can still handle duplicates if deduplication exists.

3. Final Answer:

   No deduplication in event processing -> Option C

4. Quick Check:

   Duplicates = missing deduplication [OK]

Hint: Duplicates mean missing deduplication step [OK]

Common Mistakes:

• Blaming user preferences for duplicates
• Confusing synchronous sending with duplication
• Assuming single queue causes duplicates

5. You need to design a notification system that supports email, SMS, and push notifications with user preferences and high scalability. Which architecture pattern best fits this requirement?

hard

A. Event-driven microservices with message queues and preference service

B. Batch processing system sending notifications once daily

C. Single database polling for notifications every minute

D. Monolithic application with direct notification calls

Solution

1. Step 1: Identify scalability and multi-channel needs

   Supporting multiple notification types and scaling requires decoupling components and asynchronous processing.

2. Step 2: Match architecture patterns

   Event-driven microservices with message queues allow independent scaling, handle user preferences, and support multiple channels efficiently.

3. Step 3: Eliminate unsuitable options

   Monolithic apps limit scalability; polling causes delays; batch processing is too slow for timely notifications.

4. Final Answer:

   Event-driven microservices with message queues and preference service -> Option A

5. Quick Check:

   Scalable multi-channel = event-driven microservices [OK]

Hint: Use event-driven microservices for scalable multi-channel notifications [OK]

Common Mistakes:

• Choosing monolithic for scalability
• Using batch processing for real-time needs
• Relying on polling causing delays