Bird
Raised Fist0
HLDsystem_design~10 mins

Design a notification system in HLD - Interactive Code Practice

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Practice - 5 Tasks
Answer the questions below
1fill in blank
easy

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

HLD
The component that sends notifications to users is called the [1].
Drag options to blanks, or click blank then click option'
ALoad Balancer
BUser Interface
CDatabase
DNotification Dispatcher
Attempts:
3 left
💡 Hint
Common Mistakes
Confusing the database with the sender component.
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 for fast key-value lookups.
Drag options to blanks, or click blank then click option'
AGraph
BRelational
CKey-Value
DTime-Series
Attempts:
3 left
💡 Hint
Common Mistakes
Choosing relational database which is less efficient here.
3fill in blank
hard

Fix the error in the notification delivery flow by selecting the correct component that handles retries.

HLD
If a notification fails to deliver, the [1] component retries sending it after a delay.
Drag options to blanks, or click blank then click option'
ARetry Service
BLoad Balancer
CUser Interface
DDatabase
Attempts:
3 left
💡 Hint
Common Mistakes
Confusing load balancer with retry logic.
4fill in blank
hard

Fill both blanks to complete the notification system's architecture components.

HLD
The [1] queues incoming notifications, while the [2] sends them to users.
Drag options to blanks, or click blank then click option'
AMessage Broker
BUser Interface
CNotification Dispatcher
DDatabase
Attempts:
3 left
💡 Hint
Common Mistakes
Mixing up UI with sending component.
5fill in blank
hard

Fill all three blanks to complete the notification filtering logic.

HLD
Notifications are filtered by [1] before sending. The system checks [2] to respect user choices and uses [3] to avoid overload.
Drag options to blanks, or click blank then click option'
Apriority
Buser preferences
Crate limiting
Ddatabase
Attempts:
3 left
💡 Hint
Common Mistakes
Confusing database with filtering logic.

Practice

(1/5)
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