Mediator pattern in LLD - System Design Exercise

Design: Mediator Pattern Implementation

Design the mediator pattern structure and communication flow between components. Out of scope: persistence, distributed system scaling, UI design.

Functional Requirements

FR1: Allow multiple components (colleagues) to communicate without knowing each other directly

FR2: Centralize communication logic in a mediator component

FR3: Support adding new components without changing existing ones

FR4: Ensure components can send and receive messages via the mediator

FR5: Handle message routing and coordination between components

Non-Functional Requirements

NFR1: System should support up to 100 concurrent components

NFR2: Message delivery latency should be under 50ms

NFR3: Mediator should be a single point of communication but avoid becoming a bottleneck

NFR4: System should be easy to extend with new component types

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

Mediator interface and concrete mediator implementation

Colleague components that communicate via the mediator

Message or event objects passed between components

Registration mechanism for components

Communication protocol (method calls, events, callbacks)

Design Patterns

Observer pattern for event notification

Command pattern for encapsulating requests

Singleton pattern if mediator should be unique

Dependency injection for mediator and colleagues

Reference Architecture

          +-------------------+
          |    Mediator       |
          |  (central hub)    |
          +---------+---------+
                    |
    +---------------+---------------+
    |               |               |
+---+---+       +---+---+       +---+---+
|Comp A |       |Comp B |       |Comp C |
+-------+       +-------+       +-------+

Components

Mediator Interface

Abstract class or interface

Defines methods for communication between components

Concrete Mediator

Class implementing Mediator Interface

Coordinates communication and message routing between components

Colleague Components

Classes implementing a common interface

Send and receive messages only via the mediator

Message/Event Objects

Simple data structures or classes

Encapsulate information passed between components

Registration Mechanism

Methods in mediator

Allow components to register and deregister themselves

Request Flow

1. 1. Component A sends a message to the mediator.

2. 2. Mediator receives the message and determines target components.

3. 3. Mediator forwards the message to Component B and/or Component C.

4. 4. Components B and C process the message and optionally respond via mediator.

5. 5. Mediator routes any responses back to the original sender or other components.

Database Schema

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

Scaling Discussion

Bottlenecks

Mediator becomes a single point of failure and performance bottleneck as number of components grows

High message volume can cause latency increase

Complex routing logic can slow down message delivery

Solutions

Implement mediator as a distributed or replicated service to avoid single point of failure

Use asynchronous message queues inside mediator to handle high volume

Optimize routing logic with efficient data structures or indexing

Partition components into groups with separate mediators to reduce load

Interview Tips

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

Explain how mediator decouples components to reduce dependencies

Describe component registration and message routing clearly

Discuss pros and cons of centralized communication

Mention how to handle scaling and fault tolerance

Use simple examples to illustrate message flow

Practice

1. What is the main purpose of the Mediator pattern in system design?

easy

A. To store data persistently in a database

B. To increase direct communication between all components

C. To replace all components with a single monolithic class

D. To centralize communication between components and reduce dependencies

Solution

1. Step 1: Understand the role of Mediator

   The Mediator pattern acts as a central hub to manage communication between components, avoiding direct links between them.

2. Step 2: Compare options with Mediator's purpose

   To centralize communication between components and reduce dependencies correctly states the purpose: centralizing communication and reducing dependencies. Other options describe unrelated or incorrect behaviors.

3. Final Answer:

   To centralize communication between components and reduce dependencies -> Option D

4. Quick Check:

   Mediator centralizes communication = A [OK]

Hint: Mediator centralizes communication, not direct links [OK]

Common Mistakes:

• Thinking Mediator increases direct component communication
• Confusing Mediator with data storage patterns
• Assuming Mediator merges components into one

2. Which of the following is the correct way to define a Mediator interface in a low-level design?

easy

A. interface Mediator { void notify(Component sender, String event); }

B. class Mediator { void notifyAll(); }

C. interface Mediator { void sendMessage(String message); }

D. class Mediator { void receive(Component sender); }

Solution

1. Step 1: Identify typical Mediator method signature

   The Mediator usually has a method to notify it about events from components, often with sender and event details.

2. Step 2: Match method signatures to this pattern

   interface Mediator { void notify(Component sender, String event); } matches this pattern with notify(Component sender, String event). Others lack sender info or use incorrect method names.

3. Final Answer:

   interface Mediator { void notify(Component sender, String event); } -> Option A

4. Quick Check:

   Notify method with sender and event = B [OK]

Hint: Mediator notify method includes sender and event [OK]

Common Mistakes:

• Omitting sender parameter in notify method
• Using generic sendMessage without context
• Naming methods incorrectly for Mediator role

3. Given the following code snippet, what will be the output?

class Mediator {
  notify(sender, event) {
    if (event === 'A') return 'Handled A';
    if (event === 'B') return 'Handled B';
    return 'Unknown event';
  }
}

const mediator = new Mediator();
console.log(mediator.notify('Component1', 'B'));

medium

A. Handled A

B. Error: notify method missing

C. Handled B

D. Unknown event

Solution

1. Step 1: Analyze notify method logic

   The method returns 'Handled A' if event is 'A', 'Handled B' if event is 'B', else 'Unknown event'.

2. Step 2: Check the call with event 'B'

   The call is mediator.notify('Component1', 'B'), so it matches the second condition and returns 'Handled B'.

3. Final Answer:

   Handled B -> Option C

4. Quick Check:

   Event 'B' returns 'Handled B' [OK]

Hint: Match event string exactly in notify method [OK]

Common Mistakes:

• Confusing event 'B' with 'A'
• Assuming default case triggers for known events
• Expecting error due to missing parameters

4. In the following Mediator implementation, what is the main issue?

class Mediator {
  notify(sender, event) {
    if (event === 'start') {
      sender.start();
    } else if (event === 'stop') {
      sender.stop();
    }
  }
}

class Component {
  start() { console.log('Started'); }
  stop() { console.log('Stopped'); }
}

const mediator = new Mediator();
const comp = new Component();
mediator.notify(comp, 'start');

medium

A. Component class lacks notify method

B. Mediator calls methods on sender directly, creating tight coupling

C. notify method does not handle unknown events

D. Missing constructor in Mediator class

Solution

1. Step 1: Review Mediator's notify method behavior

   The Mediator calls start() or stop() directly on the sender component.

2. Step 2: Identify design issue

   This direct call creates tight coupling between Mediator and Component, defeating the purpose of loose coupling in Mediator pattern.

3. Final Answer:

   Mediator calls methods on sender directly, creating tight coupling -> Option B

4. Quick Check:

   Tight coupling breaks Mediator pattern goal = A [OK]

Hint: Mediator should avoid calling sender methods directly [OK]

Common Mistakes:

• Ignoring tight coupling caused by direct calls
• Thinking missing notify in Component is an error
• Assuming constructor absence causes failure

5. You are designing a chat application where multiple users send messages to each other. Which design using the Mediator pattern best fits this scenario?

hard

A. A ChatRoom mediator receives messages from users and forwards them to the intended recipients.

B. Users store messages locally and synchronize with a database periodically.

C. Each user sends messages directly to all other users without a central controller.

D. Users communicate only through email notifications handled by a separate service.

Solution

1. Step 1: Understand the chat communication needs

   Users need a central place to send and receive messages without direct dependencies on each other.

2. Step 2: Match with Mediator pattern usage

   A ChatRoom mediator receives messages from users and forwards them to the intended recipients. describes a ChatRoom mediator that manages message routing, fitting the Mediator pattern perfectly.

3. Final Answer:

   A ChatRoom mediator receives messages from users and forwards them to the intended recipients. -> Option A

4. Quick Check:

   Central message routing = C [OK]

Hint: Mediator centralizes message routing in chat apps [OK]

Common Mistakes:

• Choosing direct user-to-user messaging (no mediator)
• Confusing data storage with communication pattern
• Selecting unrelated communication methods