Notification system design in HLD - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to identify the main component responsible for sending notifications.

HLD

The component that handles sending notifications to users is called the [1].

Drag options to blanks, or click blank then click option'

ACache Server

BUser Database

CLoad Balancer

DNotification Dispatcher

Attempts:

3 left

💡 Hint

Common Mistakes

Confusing the dispatcher with the user database.

Choosing load balancer as it handles traffic but not notifications.

The Notification Dispatcher is the main component that sends notifications to users.

2fill in blank

medium

Complete the code to specify the type of database best suited for storing user notification preferences.

HLD

For storing user notification preferences, a [1] database is preferred because it handles flexible data well.

Drag options to blanks, or click blank then click option'

ARelational

BNoSQL

CIn-memory

DTime-series

Attempts:

3 left

💡 Hint

Common Mistakes

Choosing relational databases which require fixed schemas.

Selecting in-memory databases which are volatile.

NoSQL databases are good for flexible and scalable storage of user preferences.

3fill in blank

hard

Fix the error in the notification delivery flow by completing the missing step.

HLD

User sends a request → [1] → Notification Queue → Notification Dispatcher → User device

Drag options to blanks, or click blank then click option'

ANotification Generator

BDatabase

CCache Server

DLoad Balancer

Attempts:

3 left

💡 Hint

Common Mistakes

Choosing Load Balancer which routes traffic but does not generate notifications.

Selecting Database which stores data but does not create notifications.

The Notification Generator creates the notification message before it is queued for delivery.

4fill in blank

hard

Fill both blanks to complete the code for a scalable notification system architecture.

HLD

Use a [1] to distribute incoming requests and a [2] to handle message storage and retries.

Drag options to blanks, or click blank then click option'

ALoad Balancer

BNotification Queue

CCache Server

DUser Database

Attempts:

3 left

💡 Hint

Common Mistakes

Mixing up cache server with queue for message handling.

Using user database for message retries.

A Load Balancer distributes requests evenly, and a Notification Queue manages message storage and retries.

5fill in blank

hard

Fill all three blanks to complete the code for a notification system that supports multiple channels.

HLD

Notifications are sent via [1], [2], and [3] to reach users on different devices.

Drag options to blanks, or click blank then click option'

AEmail

BSMS

CPush Notification

DFTP

Attempts:

3 left

💡 Hint

Common Mistakes

Including FTP which is not used for notifications.

Missing push notifications which are common on mobile devices.

Email, SMS, and Push Notification are common channels used to deliver notifications to users.

Practice

1. Which component in a notification system is primarily responsible for storing user preferences about how they want to receive notifications?

easy

A. User Management Service

B. Notification Delivery Service

C. Notification Queue

D. Notification Generator

Solution

1. Step 1: Understand user preferences role

   User preferences define how users want to receive notifications (email, SMS, push).

2. Step 2: Identify responsible component

   The User Management Service stores and manages user data including preferences.

3. Final Answer:

   User Management Service -> Option A

4. Quick Check:

   User preferences stored in User Management Service [OK]

Hint: User preferences belong to user data, so User Management Service [OK]

Common Mistakes:

• Confusing Notification Queue as storage for preferences
• Thinking Notification Delivery Service stores preferences
• Assuming Notification Generator manages user data

2. Which of the following is the correct sequence of components involved in sending a notification from creation to delivery?

easy

A. User Management Service -> Notification Delivery Service -> Notification Generator

B. Notification Delivery Service -> Notification Queue -> Notification Generator

C. Notification Queue -> Notification Generator -> Notification Delivery Service

D. Notification Generator -> Notification Queue -> Notification Delivery Service

Solution

1. Step 1: Understand notification flow

   Notifications are created, queued, then delivered.

2. Step 2: Match correct order

   Notification Generator creates, Notification Queue holds, Delivery Service sends.

3. Final Answer:

   Notification Generator -> Notification Queue -> Notification Delivery Service -> Option D

4. Quick Check:

   Creation, queue, delivery order = A [OK]

Hint: Notifications flow: create, queue, then deliver [OK]

Common Mistakes:

• Mixing delivery before queuing
• Starting with delivery service instead of generator
• Ignoring the queue component

3. Consider this simplified flow: A notification is created and placed in a queue. The delivery service fetches notifications from the queue and sends them. If the delivery service crashes after fetching but before sending, what happens to the notification?

medium

A. Notification is lost and never sent

B. Notification is duplicated and sent twice

C. Notification remains in the queue for retry

D. Notification is sent immediately by the generator

Solution

1. Step 1: Analyze delivery service crash timing

   Crash occurs after fetching from queue but before sending notification.

2. Step 2: Understand queue behavior with acknowledgment

   Without acknowledgment, message stays or returns to queue for retry.

3. Final Answer:

   Notification remains in the queue for retry -> Option C

4. Quick Check:

   Unacknowledged messages stay in queue [OK]

Hint: Unsent messages stay in queue until confirmed sent [OK]

Common Mistakes:

• Assuming notification is lost without retry
• Thinking notification is duplicated automatically
• Believing generator sends notification directly

4. A notification system is experiencing delays because the delivery service processes notifications sequentially. Which change will best improve throughput without losing message order?

medium

A. Store notifications only in the database without queue

B. Add multiple delivery service instances with partitioned queues

C. Use a single-threaded delivery service with longer timeouts

D. Remove the queue and send notifications directly

Solution

1. Step 1: Identify bottleneck cause

   Sequential processing limits throughput.

2. Step 2: Apply partitioned queues with multiple instances

   Partitioning allows parallel processing while preserving order per partition.

3. Final Answer:

   Add multiple delivery service instances with partitioned queues -> Option B

4. Quick Check:

   Parallelism with partitioning improves throughput [OK]

Hint: Partition queues to parallelize delivery without breaking order [OK]

Common Mistakes:

• Removing queue loses reliability and order
• Single-threaded service slows throughput
• Storing only in DB delays delivery

5. You need to design a notification system that supports millions of users with different notification preferences and guarantees delivery within seconds. Which architectural approach best meets these requirements?

hard

A. Implement microservices with separate components for user preferences, notification generation, queuing, and delivery with horizontal scaling

B. Use a monolithic service handling all notifications synchronously

C. Store all notifications in a single database table and poll it every minute for delivery

D. Send notifications directly from the user management service without queues

Solution

1. Step 1: Analyze scalability and latency needs

   Millions of users and seconds-level delivery require scalable, decoupled design.

2. Step 2: Choose microservices with separate components and horizontal scaling

   This approach allows independent scaling, fault isolation, and faster processing.

3. Final Answer:

   Implement microservices with separate components for user preferences, notification generation, queuing, and delivery with horizontal scaling -> Option A

4. Quick Check:

   Microservices + scaling = scalable, fast delivery [OK]

Hint: Decouple components and scale horizontally for millions of users [OK]

Common Mistakes:

• Using monolith limits scalability and speed
• Polling DB every minute causes delays
• Skipping queues reduces reliability