Mediator pattern in LLD - Scalability & System Analysis

Scalability Analysis - Mediator pattern

Growth Table: Mediator Pattern

Users / Components	100	10,000	1,000,000	100,000,000
Number of components communicating	10-20	100-200	1,000-2,000	10,000+
Messages per second through mediator	100-500	5,000-10,000	100,000-200,000	10M+
Mediator complexity	Simple centralized logic	Moderate, some async handling	High, needs concurrency control	Very high, requires distributed mediator
Latency impact	Low	Moderate	High	Very high without partitioning
Single point of failure risk	High	High	Critical	Critical

First Bottleneck

The mediator component becomes the first bottleneck as the number of components and messages grow. It must handle all communication, so CPU and memory usage spike. At medium scale (10,000+ components), the mediator's processing and message routing slows down, increasing latency. At large scale, the single mediator cannot handle the load, causing delays and failures.

Scaling Solutions

• Horizontal scaling: Split the mediator into multiple instances, each handling a subset of components (partitioning). Use a directory or registry service to route messages to the correct mediator.
• Asynchronous messaging: Use message queues or event buses to decouple senders and receivers, reducing blocking and improving throughput.
• Caching: Cache frequent communication patterns or results to reduce mediator processing.
• Load balancing: Distribute incoming messages evenly across mediator instances.
• Sharding: Partition components by domain or function to reduce mediator load.
• Failover and redundancy: Use multiple mediator instances with health checks to avoid single points of failure.

Back-of-Envelope Cost Analysis

• At 10,000 components sending 10 messages/sec each, mediator handles ~100,000 messages/sec.
• Assuming 1 KB per message, bandwidth needed is ~100 MB/s (800 Mbps).
• CPU load depends on message processing complexity; expect multiple cores or distributed mediators.
• Memory needed depends on message queue sizes and state; estimate several GBs for buffering.
• Storage for logs or message history grows with message volume; plan for scalable storage solutions.

Interview Tip

Start by explaining the mediator pattern's role in centralizing communication. Discuss how it simplifies component interactions but can become a bottleneck as scale grows. Then, outline how you would identify bottlenecks (CPU, memory, latency) and propose scaling strategies like partitioning the mediator, asynchronous messaging, and load balancing. Always connect your solutions to the specific bottleneck you identified.

Self Check Question

Your mediator handles 1,000 messages per second. Traffic grows 10x. What do you do first and why?

Answer: The mediator is the bottleneck. First, partition the mediator into multiple instances to distribute the load. This reduces CPU and memory pressure on a single mediator and improves throughput.

Key Result

The mediator pattern centralizes communication but becomes a bottleneck as message volume grows; partitioning and asynchronous messaging are key to scaling.

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