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