Observer pattern in LLD - System Design Exercise

Design: Observer Pattern Implementation

Design and implement the core observer pattern components including subject and observers. Out of scope are UI frameworks or network communication.

Functional Requirements

FR1: Allow multiple observer objects to subscribe to a subject object.

FR2: Notify all subscribed observers automatically when the subject's state changes.

FR3: Support adding and removing observers at runtime.

FR4: Ensure observers receive updates in a timely manner after state changes.

FR5: Keep the subject and observers loosely coupled.

Non-Functional Requirements

NFR1: The notification latency should be minimal (under 100ms) for typical state changes.

NFR2: Support up to 1000 observers per subject without significant performance degradation.

NFR3: Ensure thread safety if multiple threads update the subject or observers.

NFR4: Memory usage should be efficient to handle many observers.

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

Subject interface/class to manage observers and state

Observer interface/class to receive updates

Concrete subject implementing state changes

Concrete observers implementing reaction to updates

Notification mechanism (push or pull model)

Design Patterns

Publish-Subscribe pattern

Event-driven architecture

Callback functions or listener interfaces

Thread-safe observer management

Reference Architecture

          +----------------+
          |    Subject     |
          |----------------|
          | - observers[]  |
          | + attach()     |
          | + detach()     |
          | + notify()     |
          +--------+-------+
                   |
        +----------+----------+
        |                     |
+---------------+     +---------------+
|  Observer 1   |     |  Observer 2   |
|---------------|     |---------------|
| + update()    |     | + update()    |
+---------------+     +---------------+

Components

Subject

Class or Interface

Manages a list of observers and notifies them of state changes.

Observer

Interface or Abstract Class

Defines the update method that observers implement to receive notifications.

ConcreteSubject

Class

Implements Subject, holds state, and notifies observers when state changes.

ConcreteObserver

Class

Implements Observer, reacts to updates from the subject.

Request Flow

1. 1. Observer calls attach() on Subject to subscribe.

2. 2. Subject stores observer reference in its list.

3. 3. Subject state changes via some method.

4. 4. Subject calls notify(), iterating over observers.

5. 5. Each observer's update() method is called with new state or event.

6. 6. Observers react accordingly to the update.

7. 7. Observers can call detach() to unsubscribe.

Database Schema

Not applicable as this is an in-memory design pattern implementation without persistent storage.

Scaling Discussion

Bottlenecks

Large number of observers causing slow notification loops.

Thread safety issues when multiple threads modify observers or subject state.

Observers that take too long to process updates blocking others.

Memory overhead from storing many observer references.

Solutions

Use asynchronous notification (e.g., event queues) to avoid blocking.

Implement thread-safe data structures or synchronization for observer list.

Use weak references for observers to avoid memory leaks.

Batch notifications or filter observers to reduce notification load.

Interview Tips

Time: Spend 10 minutes explaining the problem and requirements, 15 minutes designing the components and data flow, 10 minutes discussing scaling and thread safety, and 10 minutes answering questions.

Explain the loose coupling benefit of the observer pattern.

Describe how observers register and get notified.

Discuss synchronous vs asynchronous notifications.

Highlight thread safety and performance considerations.

Mention real-world examples like UI event listeners or messaging systems.