Notification on state change in LLD - Scalability & System Analysis

Scalability Analysis - Notification on state change

Growth Table: Notification on State Change

Users	Notifications per second	System Changes	Storage & Bandwidth
100 users	~10-50	Single server handles events and notifications synchronously	Minimal storage, low bandwidth
10,000 users	~1,000-5,000	Introduce async processing with message queues; database indexing for state changes	Moderate storage for logs, moderate bandwidth
1,000,000 users	~100,000+	Horizontal scaling of app servers; distributed message queues; caching notifications; database sharding	High storage for notification history; high bandwidth; CDN for static content
100,000,000 users	~10,000,000+	Multi-region deployment; global load balancing; event streaming platforms; advanced sharding and partitioning; real-time analytics	Massive storage with tiered archival; very high bandwidth; CDN and edge computing

First Bottleneck

At small scale, the database is the first bottleneck because it must track state changes and notification statuses. As users grow, synchronous writes and reads overload the DB.

Scaling Solutions

• Async Processing: Use message queues (e.g., Kafka, RabbitMQ) to decouple state change detection from notification sending.
• Horizontal Scaling: Add more application servers behind load balancers to handle increased notification processing.
• Caching: Cache frequent state queries and notification templates to reduce DB load.
• Database Sharding: Partition the database by user ID or region to distribute load.
• CDN & Edge: Use CDN to deliver static notification content and reduce latency.
• Event Streaming: Employ event streaming platforms for real-time, scalable state change propagation.

Back-of-Envelope Cost Analysis

• At 1M users with 0.1 notifications/user/sec -> 100,000 notifications/sec.
• Each notification ~1KB payload -> 100 MB/s bandwidth needed.
• Storage for notification logs: 100,000 notifications/sec x 1KB x 3600 sec = ~360 GB/hour.
• Database QPS: 100,000+ writes/sec, requiring sharding and replicas.
• Network bandwidth: Multiple 1 Gbps links or 10 Gbps aggregation.

Interview Tip

Start by clarifying notification volume and latency needs. Identify the bottleneck (usually DB). Discuss async decoupling, horizontal scaling, caching, and data partitioning. Show awareness of trade-offs like consistency vs latency.

Self Check

Your database handles 1000 QPS. Traffic grows 10x. What do you do first?

Answer: Introduce read replicas and caching to reduce DB load, and move notification processing to async queues to smooth spikes.

Key Result

The database is the first bottleneck as users and notifications grow; scaling requires async processing, horizontal app scaling, caching, and database sharding to handle high notification volumes efficiently.

Practice

1. What is the main purpose of a notification system on state change in software design?

easy

A. To inform interested components immediately when data changes

B. To store data permanently in a database

C. To increase the size of the application

D. To delay updates until the user refreshes manually

Solution

1. Step 1: Understand the role of notifications

   Notifications alert parts of a system or users when something important changes.

2. Step 2: Identify the purpose of state change notifications

   They ensure components get updates immediately without waiting or manual refresh.

3. Final Answer:

   To inform interested components immediately when data changes -> Option A

4. Quick Check:

   Notification = Immediate update [OK]

Hint: Notifications alert on change, not store or delay [OK]

Common Mistakes:

• Confusing notification with data storage
• Thinking notifications delay updates
• Assuming notifications increase app size

2. Which of the following is the correct method name to notify observers in a typical observer pattern implementation?

easy

A. unsubscribe()

B. updateState()

C. subscribe()

D. notifyObservers()

Solution

1. Step 1: Recall observer pattern methods

   Common methods include subscribe, unsubscribe, and notifyObservers.

2. Step 2: Identify the method that sends updates

   notifyObservers() is used to alert all subscribed observers about changes.

3. Final Answer:

   notifyObservers() -> Option D

4. Quick Check:

   Notify method = notifyObservers() [OK]

Hint: Notify method usually named notifyObservers() [OK]

Common Mistakes:

• Confusing subscribe with notify
• Using updateState() which changes state, not notify
• Mixing unsubscribe with notification

3. Consider this simplified code snippet for a notification system:

class Subject:
    def __init__(self):
        self.observers = []
    def subscribe(self, observer):
        self.observers.append(observer)
    def notify(self, message):
        for obs in self.observers:
            obs.update(message)

class Observer:
    def update(self, message):
        print(f"Received: {message}")

subject = Subject()
obs1 = Observer()
subject.subscribe(obs1)
subject.notify("State changed")

What will be the output when subject.notify("State changed") is called?

medium

A. Error: update method missing

B. No output

C. Received: State changed

D. Received: None

Solution

1. Step 1: Trace subscription and notification

   Observer obs1 is subscribed to subject, so it is in the observers list.

2. Step 2: Check notify method behavior

   notify calls update on each observer with the message "State changed".

3. Final Answer:

   Received: State changed -> Option C

4. Quick Check:

   Observer prints message on notify [OK]

Hint: Subscribed observers receive and print messages [OK]

Common Mistakes:

• Assuming notify does nothing without explicit call
• Thinking update method is missing
• Expecting no output if observers list is empty

4. In the following code, what is the main issue that prevents observers from receiving notifications?

class Subject:
    def __init__(self):
        self.observers = set()
    def subscribe(self, observer):
        self.observers.add(observer)
    def notify(self, message):
        for obs in self.observers:
            obs.receive(message)

class Observer:
    def update(self, message):
        print(f"Got: {message}")

subject = Subject()
obs1 = Observer()
subject.subscribe(obs1)
subject.notify("Update")

medium

A. Observers are stored in a set instead of a list

B. Method notify calls obs.receive but Observer has update method

C. subscribe method uses add instead of append

D. Observer class is missing

Solution

1. Step 1: Check method called in notify

   notify() calls obs.receive(message).

2. Step 2: Check Observer class methods

   Observer defines update(message), but no receive() method.

3. Final Answer:

   Method notify calls obs.receive but Observer has update method -> Option B

4. Quick Check:

   Method name mismatch causes AttributeError [OK]

Hint: Check method names called vs defined in observers [OK]

Common Mistakes:

• Confusing set vs list for storing observers
• Ignoring method name mismatches
• Assuming missing class when it exists

5. You are designing a scalable notification system for state changes in a distributed application. Which design choice best supports efficient notifications to thousands of subscribers without blocking the main process?

hard

A. Use asynchronous message queues to dispatch notifications

B. Notify all subscribers synchronously in a loop

C. Store notifications in a database and poll subscribers

D. Send notifications only when the system restarts

Solution

1. Step 1: Understand scalability needs

   Thousands of subscribers require non-blocking, efficient notification delivery.

2. Step 2: Evaluate design options

   Synchronous loops block main process; polling adds delay; restart notifications are impractical.

3. Step 3: Identify best practice

   Asynchronous message queues decouple notification sending, allowing scalable, fast delivery.

4. Final Answer:

   Use asynchronous message queues to dispatch notifications -> Option A

5. Quick Check:

   Async queues = scalable notifications [OK]

Hint: Async queues handle many subscribers efficiently [OK]

Common Mistakes:

• Using synchronous loops causing delays
• Relying on polling which is slow
• Sending notifications only on restart