Mediator pattern in LLD - System Design Guide

Problem Statement

When multiple components communicate directly with each other, the system becomes tightly coupled and complex. Changes in one component can cause ripple effects, making maintenance and scaling difficult.

Solution

The Mediator pattern introduces a central object that handles communication between components. Instead of talking directly, components send messages to the mediator, which then routes them appropriately, reducing dependencies and simplifying interactions.

Architecture

Component A

↓

Component B

↓

Component C

This diagram shows multiple components communicating only through a central Mediator, which manages all interactions and routes messages.

Trade-offs

✓ Pros

→

Reduces direct dependencies between components, making the system easier to maintain.

→

Centralizes control of communication, simplifying debugging and modification.

→

Improves code reusability by decoupling components from each other.

✗ Cons

→

Mediator can become a complex, monolithic component if not designed carefully.

→

Introduces an extra layer of indirection, which may add slight performance overhead.

→

Overuse can lead to a single point of failure or bottleneck in communication.

Use when multiple components interact in complex ways and tight coupling makes maintenance or scaling difficult, especially in UI event handling or messaging systems.

Avoid when components have simple, direct interactions or when the number of components is very small, as the mediator adds unnecessary complexity.

Real World Examples

Airbnb

Uses Mediator pattern in their booking system to coordinate interactions between availability, pricing, and payment components without tight coupling.

Discord

Applies Mediator pattern to manage communication between different chat modules and notification systems, centralizing message routing.

LinkedIn

Uses Mediator pattern in their UI components to handle complex user interactions and event propagation cleanly.

Code Example

Before: ComponentA calls ComponentB directly, creating tight coupling. After: Both components communicate only through the Mediator, which routes events and reduces dependencies.

LLD

### Before applying Mediator pattern (tight coupling)

class ComponentA:
    def __init__(self, component_b):
        self.component_b = component_b

    def do_a(self):
        print("Component A does something")
        self.component_b.do_b()

class ComponentB:
    def do_b(self):
        print("Component B does something")

# Usage
b = ComponentB()
a = ComponentA(b)
a.do_a()


### After applying Mediator pattern (decoupled communication)

class Mediator:
    def __init__(self):
        self.component_a = ComponentA(self)
        self.component_b = ComponentB(self)

    def notify(self, sender, event):
        if sender == self.component_a and event == "A_done":
            self.component_b.do_b()

class ComponentA:
    def __init__(self, mediator):
        self.mediator = mediator

    def do_a(self):
        print("Component A does something")
        self.mediator.notify(self, "A_done")

class ComponentB:
    def __init__(self, mediator):
        self.mediator = mediator

    def do_b(self):
        print("Component B does something")

# Usage
mediator = Mediator()
mediator.component_a.do_a()

Alternatives

Observer pattern

Observer allows components to subscribe to events directly, while Mediator centralizes communication through one object.

Use when: Choose Observer when you want a one-to-many dependency without central control.

Event Bus

Event Bus is a more decoupled, publish-subscribe system without a central mediator controlling all interactions.

Use when: Choose Event Bus for highly decoupled systems with many independent event producers and consumers.

Summary

Mediator pattern centralizes communication between components to reduce tight coupling.

It simplifies maintenance by routing interactions through a single mediator object.

Overuse can cause the mediator to become complex and a potential bottleneck.