Notification system in LLD - Architecture Diagram

System Overview - Notification system

This notification system sends messages to users through multiple channels like email, SMS, and push notifications. It must handle high volumes of notifications reliably and deliver them quickly.

Architecture Diagram

User
  |
  v
Load Balancer
  |
  v
API Gateway
  |
  v
Notification Service
  |          |           |
  v          v           v
Email Service SMS Service Push Service
  |          |           |
  v          v           v
Email Server SMS Gateway Push Server

Database <-> Message Queue <-> Notification Service
Cache <-> Notification Service

Components

User

client

Initiates notification requests

Load Balancer

load_balancer

Distributes incoming requests evenly to API Gateway instances

API Gateway

api_gateway

Handles client requests, routes them to Notification Service

Notification Service

service

Processes notification requests, decides delivery channels

Message Queue

queue

Buffers notification tasks for asynchronous processing

Email Service

service

Sends email notifications

SMS Service

service

Sends SMS notifications

Push Service

service

Sends push notifications

Email Server

external_service

Delivers emails to user inboxes

SMS Gateway

external_service

Delivers SMS messages to mobile networks

Push Server

external_service

Delivers push notifications to devices

Database

database

Stores user preferences and notification history

Cache

cache

Stores frequently accessed user data for quick retrieval

Request Flow - 18 Hops

User → Load Balancer

Load Balancer → API Gateway

API Gateway → Notification Service

Notification Service → Cache

Cache → Notification Service

Notification Service → Database

Database → Notification Service

Notification Service → Message Queue

Message Queue → Email Service

Email Service → Email Server

Message Queue → SMS Service

SMS Service → SMS Gateway

Message Queue → Push Service

Push Service → Push Server

Notification Service → Database

Notification Service → API Gateway

API Gateway → Load Balancer

Load Balancer → User

Failure Scenario

Component Fails:Message Queue

Impact:Notification tasks cannot be buffered, causing delays or loss of notifications

Mitigation:Use queue replication and fallback to direct synchronous processing with rate limiting

Architecture Quiz - 3 Questions

Which component is responsible for distributing incoming user requests evenly?

A API Gateway

B Load Balancer

C Notification Service

D Message Queue

Design Principle

This design uses asynchronous processing with a message queue to handle high notification volumes reliably. Caching user preferences reduces database load and speeds up processing. Load balancing and API gateway ensure scalability and security.

Practice

1. Which component in a notification system is responsible for generating events that trigger notifications?

easy

A. Delivery Channel

B. Notification Service

C. User Preferences Store

D. Event Producer

Solution

1. Step 1: Understand the role of event producers

   Event producers create or detect events that require notifying users, such as a new message or alert.

2. Step 2: Differentiate from other components

   Notification service processes events, delivery channels send notifications, and user preferences store user settings.

3. Final Answer:

   Event Producer -> Option D

4. Quick Check:

   Event source = Event Producer [OK]

Hint: Event creators are called producers in notification systems [OK]

Common Mistakes:

• Confusing notification service with event producer
• Thinking delivery channel generates events
• Assuming user preferences create events

2. Which of the following is the correct sequence of components for sending a notification after an event occurs?

easy

A. Delivery Channel -> Notification Service -> Event Producer

B. Event Producer -> Notification Service -> Delivery Channel

C. Notification Service -> Event Producer -> Delivery Channel

D. User Preferences Store -> Event Producer -> Delivery Channel

Solution

1. Step 1: Identify the logical flow of notification

   First, an event is generated by the event producer, then processed by the notification service, and finally sent via the delivery channel.

2. Step 2: Eliminate incorrect sequences

   Delivery channel cannot start the process; user preferences store is not part of the sending sequence.

3. Final Answer:

   Event Producer -> Notification Service -> Delivery Channel -> Option B

4. Quick Check:

   Event -> Process -> Send = A [OK]

Hint: Notifications flow from event to service to delivery [OK]

Common Mistakes:

• Reversing the order of components
• Including user preferences in the sending chain
• Confusing delivery channel as event source

3. Consider a notification system where users can choose email or SMS as delivery channels. If a user prefers both, what is the expected behavior when an event triggers a notification?

medium

A. Send notification via both email and SMS

B. Send notification via email only

C. Send notification via SMS only

D. Do not send any notification

Solution

1. Step 1: Understand user preference handling

   If a user selects multiple delivery channels, the system should send notifications through all preferred channels to ensure delivery.

2. Step 2: Confirm expected multi-channel delivery

   Sending via both email and SMS respects user choice and increases notification reach.

3. Final Answer:

   Send notification via both email and SMS -> Option A

4. Quick Check:

   Multiple preferences = multiple channels [OK]

Hint: Send notifications on all user-selected channels [OK]

Common Mistakes:

• Sending notification on only one channel
• Ignoring user preferences
• Not sending notification at all

4. A notification system uses a queue to handle event processing but notifications are delayed significantly. Which is the most likely cause?

medium

A. Queue is overloaded with too many events

B. User preferences are not stored

C. Delivery channel is sending notifications instantly

D. Event producer is generating too few events

Solution

1. Step 1: Analyze queue role in notification system

   Queue buffers events to handle load. If overloaded, it causes delays in processing notifications.

2. Step 2: Evaluate other options

   Missing user preferences or instant delivery does not cause delay; too few events would reduce load, not increase delay.

3. Final Answer:

   Queue is overloaded with too many events -> Option A

4. Quick Check:

   Queue overload = delay [OK]

Hint: Delays often mean queue overload, not missing data [OK]

Common Mistakes:

• Blaming delivery channel for delays
• Assuming missing preferences cause delay
• Thinking fewer events cause delays

5. You need to design a notification system that supports millions of users with personalized preferences and multiple delivery channels. Which design choice best ensures scalability and user customization?

hard

A. Use a centralized notification service with a single queue and fixed delivery channels

B. Store all user preferences in a local file on the notification server

C. Implement distributed notification services with sharded queues and dynamic delivery channel selection per user

D. Send notifications synchronously from event producers directly to users

Solution

1. Step 1: Consider scalability requirements

   Millions of users require distributed services and sharded queues to handle load without bottlenecks.

2. Step 2: Address user customization needs

   Dynamic delivery channel selection per user allows personalized notifications respecting preferences.

3. Step 3: Evaluate other options

   Centralized service and single queue create bottlenecks; synchronous sending blocks processing; local files do not scale or support dynamic preferences.

4. Final Answer:

   Implement distributed notification services with sharded queues and dynamic delivery channel selection per user -> Option C

5. Quick Check:

   Distributed + dynamic preferences = scalable & customizable [OK]

Hint: Distribute services and shard queues for scale and flexibility [OK]

Common Mistakes:

• Choosing centralized design causing bottlenecks
• Using synchronous sending blocking system
• Storing preferences in non-scalable local files