Observer pattern for UI updates in LLD - System Design Exercise

Design: Observer Pattern for UI Updates

Design focuses on the pattern and architecture for UI updates using observer pattern. Does not cover backend data storage or network communication.

Functional Requirements

FR1: Allow UI components to automatically update when underlying data changes

FR2: Support multiple UI components observing the same data source

FR3: Ensure updates are efficient and only notify components that need changes

FR4: Allow components to subscribe and unsubscribe dynamically

FR5: Handle updates in a way that avoids UI freezing or lag

Non-Functional Requirements

NFR1: Support up to 1000 concurrent UI components observing data

NFR2: UI update latency should be under 100ms after data change

NFR3: System should be simple enough to implement in typical frontend frameworks

NFR4: Memory usage should be minimal to avoid slowing down the UI

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

Subject (data source) that holds state and notifies observers

Observer (UI components) that listen for changes

Subscription management to add/remove observers

Update dispatch mechanism to notify observers

Optional batching or throttling to optimize updates

Design Patterns

Observer pattern basics

Publish-Subscribe pattern

Event-driven architecture

Debouncing or throttling updates

Weak references to avoid memory leaks

Reference Architecture

          +----------------+
          |    Subject     |
          | (Data Source)  |
          +--------+-------+
                   |
          notify() | updates
                   v
          +--------+-------+       subscribe() / unsubscribe()
          |    Observer    |<------------------------------+
          | (UI Component) |                               |
          +----------------+                               |
                   ^                                       |
                   |                                       |
          +--------+-------+                               |
          |  Observer List  |-------------------------------+

Components

Subject

Plain object or class in frontend framework

Holds the data state and manages the list of observers. Notifies observers on data changes.

Observer

UI components or widgets

Subscribe to the subject to receive updates and refresh UI accordingly.

Subscription Manager

Internal list or map data structure

Keeps track of active observers and manages adding/removing them.

Update Dispatcher

Synchronous or asynchronous event trigger

Sends notifications to observers when data changes, optionally batching updates.

Request Flow

1. 1. UI component subscribes to the subject to observe data changes.

2. 2. Subject maintains a list of subscribed observers.

3. 3. When data changes in the subject, it calls notify() to inform all observers.

4. 4. Each observer receives the update and refreshes its UI accordingly.

5. 5. Observers can unsubscribe when no longer interested or destroyed.

6. 6. Optionally, updates can be batched or throttled to improve performance.

Database Schema

Not applicable as this is a frontend design pattern without persistent storage.

Scaling Discussion

Bottlenecks

Too many observers causing slow notification and UI lag

Frequent data changes triggering excessive UI updates

Memory leaks from observers not unsubscribing properly

Cascading updates causing infinite loops or performance issues

Solutions

Implement batching or throttling to limit update frequency

Use weak references or lifecycle hooks to automatically unsubscribe observers

Design update logic to avoid cascading notifications or detect cycles

Optimize observer update methods to be lightweight and fast

Interview Tips

Time: Spend 10 minutes clarifying requirements and constraints, 20 minutes designing components and data flow, 10 minutes discussing scaling and trade-offs, 5 minutes summarizing.

Explain the roles of Subject and Observer clearly

Discuss how subscription management works

Highlight update notification flow and efficiency considerations

Mention handling of dynamic subscribe/unsubscribe

Talk about scaling challenges and solutions like batching and memory management

Practice

1. What is the main purpose of the Observer pattern in UI updates?

easy

A. To improve database query speed

B. To store user data securely

C. To automatically update UI components when data changes

D. To handle user authentication

Solution

1. Step 1: Understand the Observer pattern role

   The Observer pattern connects data changes to UI updates automatically.

2. Step 2: Match purpose with options

   Only To automatically update UI components when data changes describes automatic UI updates on data change.

3. Final Answer:

   To automatically update UI components when data changes -> Option C

4. Quick Check:

   Observer pattern = automatic UI update [OK]

Hint: Observer pattern links data changes to UI updates [OK]

Common Mistakes:

• Confusing Observer with data storage
• Thinking it improves database speed
• Mixing with authentication logic

2. Which of the following is the correct way to register an observer in the Observer pattern?

easy

A. subject.addObserver(observer)

B. observer.addSubject(subject)

C. subject.register(observer)

D. observer.register(subject)

Solution

1. Step 1: Identify who registers whom

   In the Observer pattern, the subject keeps track of observers.

2. Step 2: Choose correct method call

   The subject calls addObserver to register an observer, matching subject.addObserver(observer).

3. Final Answer:

   subject.addObserver(observer) -> Option A

4. Quick Check:

   Subject registers observers = addObserver [OK]

Hint: Subject manages observers, so use subject.addObserver() [OK]

Common Mistakes:

• Trying to register subject on observer
• Using wrong method names
• Confusing roles of subject and observer

3. Given this code snippet, what will be the output when subject.notifyObservers() is called?

class Subject:
    def __init__(self):
        self.observers = []
    def addObserver(self, obs):
        self.observers.append(obs)
    def notifyObservers(self):
        for obs in self.observers:
            obs.update('Data changed')

class Observer:
    def update(self, message):
        print(f'Observer received: {message}')

subject = Subject()
obs1 = Observer()
obs2 = Observer()
subject.addObserver(obs1)
subject.addObserver(obs2)
subject.notifyObservers()

medium

A. Observer received: Data changed
Observer received: Data changed

B. Observer received: Data changed

C. No output

D. Error: update method missing

Solution

1. Step 1: Analyze observer registration

   Two observers (obs1, obs2) are added to the subject's list.

2. Step 2: Understand notifyObservers behavior

   Calling notifyObservers calls update on each observer, printing the message twice.

3. Final Answer:

   Observer received: Data changed Observer received: Data changed -> Option A

4. Quick Check:

   Two observers print message twice [OK]

Hint: notifyObservers calls update on all registered observers [OK]

Common Mistakes:

• Assuming only one observer is notified
• Expecting no output
• Thinking update method is missing

4. Identify the bug in this Observer pattern implementation:

class Subject:
    def __init__(self):
        self.observers = set()
    def addObserver(self, obs):
        self.observers.add(obs)
    def notifyObservers(self):
        for obs in self.observers:
            obs.update('Update')

class Observer:
    def update(self, message):
        print(message)

subject = Subject()
obs = Observer()
subject.addObserver(obs)
subject.addObserver(obs)
subject.notifyObservers()

medium

A. Observers list should be a list, not a set

B. Observers are stored in a set, so duplicates are ignored

C. notifyObservers method is missing parentheses

D. Observer class lacks update method

Solution

1. Step 1: Check data structure for observers

   Observers are stored in a set, which removes duplicates automatically.

2. Step 2: Understand effect on duplicates

   Adding the same observer twice results in only one notification.

3. Final Answer:

   Observers are stored in a set, so duplicates are ignored -> Option B

4. Quick Check:

   Set removes duplicates = single notification [OK]

Hint: Sets ignore duplicates, so repeated observers notify once [OK]

Common Mistakes:

• Thinking duplicates cause multiple notifications
• Confusing set with list behavior
• Assuming missing method errors

5. You are designing a UI system where multiple components observe a shared data model. Which design choice best improves scalability and reduces UI lag when data changes rapidly?

hard

A. Notify each observer immediately on every data change without batching

B. Update UI components only on user interaction, ignoring data changes

C. Use polling in each UI component to check data changes periodically

D. Use the Observer pattern with batched notifications to observers

Solution

1. Step 1: Consider rapid data changes impact

   Immediate notifications on every change can cause UI lag and overload.

2. Step 2: Evaluate design choices for scalability

   Batching notifications reduces update frequency, improving performance and scalability.

3. Step 3: Compare with alternatives

   Polling wastes resources; ignoring data changes harms UX.

4. Final Answer:

   Use the Observer pattern with batched notifications to observers -> Option D

5. Quick Check:

   Batching notifications = scalable, smooth UI [OK]

Hint: Batch updates to observers reduce lag and improve scalability [OK]

Common Mistakes:

• Not batching causes UI lag
• Polling wastes CPU and delays updates
• Ignoring data changes breaks UI sync