Why Notification system in LLD? - Purpose & Use Cases

The Big Idea

What if you could reach millions of users instantly without lifting a finger?

The Scenario

Imagine you run a small online store and want to tell your customers when their orders ship. You try sending emails one by one manually every time an order is ready.

The Problem

Sending notifications manually is slow and tiring. You might forget some customers or send duplicate messages. As orders grow, it becomes impossible to keep up without mistakes.

The Solution

A notification system automates sending messages to users. It handles many notifications at once, keeps track of delivery, and retries if needed. This saves time and avoids errors.

Before vs After

✗ Before

for order in orders:
    send_email(order.customer_email, 'Your order shipped!')

✓ After

notification_service.send_bulk('order_shipped', orders)

What It Enables

It makes real-time, reliable communication with users possible at any scale, improving user experience and trust.

Real Life Example

Social media platforms use notification systems to instantly alert you about likes, comments, or messages without delay or missing any updates.

Key Takeaways

Manual notifications are slow and error-prone.

Notification systems automate and scale message delivery.

This leads to timely, reliable user communication.

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