Mediator Pattern: The Control Tower That Stops the Chaos

A Busy Evening at Delhi Airport 🛫

It is 7 PM at Indira Gandhi International Airport in Delhi. The monsoon clouds are heavy. The sky above the airport is full of blinking lights — every light is a plane carrying hundreds of people.

Meet our characters for this whole post. Remember their names, because they will stay with us till the end.

• Captain Meera Nair is flying IndiGo 6E-202 from Mumbai. Her fuel is getting low. She wants to land.
• Captain Arjun Rao is sitting in Air India 145 on the ground, engines warm, ready to take off for Chennai.
• Captain Divya is circling above in Vistara UK-995, waiting for her turn.
• And high up in the glass tower sits Vikram, the air traffic controller, with a radar screen, a headset, and a very calm voice.

Now think about a serious question. Three planes, one runway. Who goes first?

Imagine if there was no tower. Meera would have to call Arjun on the radio: "Arjun bhai, are you taking off now or can I land?" Arjun would have to call Divya: "Divya, how much fuel do you have? Can you wait five more minutes?" Divya would have to call Meera. Every pilot talking to every other pilot, all at the same time, in the dark, in the rain. One missed call, one wrong guess — and two planes could meet on the same runway. That word is too scary to even write.

This never happens in real life. Why? Because of Vikram.

Every pilot talks only to Vikram. Vikram sees the whole sky on his radar. He says, "IndiGo 6E-202, you are cleared to land on runway 29." He says, "Air India 145, hold your position, two minutes." He says, "Vistara UK-995, maintain 3000 feet, you are number two for landing." Meera never speaks to Arjun. Arjun never speaks to Divya. Each pilot has exactly one conversation — with the tower. And somehow, magically, the whole sky stays organised.

This is the Mediator pattern, completely and exactly. The tower is the mediator. The planes are the components. The planes never talk to each other. They only talk to the tower, and the tower coordinates everything.

In this post we will build Vikram's tower in code, three times, in three languages. We will count the wires, draw the pictures, and by the end you will know exactly when to build a control tower inside your own programs — and when not to.

What Is the Mediator Pattern?

Here is the simple definition.

Mediator is a behavioral design pattern that stops a group of objects from talking to each other directly. Instead, all of them talk to one central object — the mediator — and the mediator decides who should do what next.

Think about the shape of the connections. Without a mediator, every object may be connected to every other object. That looks like a messy spider web. With a mediator, every object has just one connection — to the mediator. That looks like a neat star, with the mediator shining in the middle.

The word "mediator" itself means "a person in the middle who helps two sides talk". In Indian families, when two relatives are not speaking to each other, often one wise uncle quietly passes messages between them at every wedding. That uncle is a mediator too. He carries the message, softens the words, and decides what to pass on and what to drop.

The pattern has four parts. Keep this list handy:

1. Mediator interface — a small contract, usually with one method like notify(sender, event). This is the "radio frequency" everyone agrees to use.
2. Concrete Mediator — the real control tower. It holds references to all components and contains all the coordination rules. Vikram with his radar.
3. Base Component — every component keeps a reference to the mediator. Every plane has a radio tuned to the tower.
4. Concrete Components — the planes themselves. They do their own small job (flying!) and report events to the mediator. They know nothing about each other.

The Problem It Solves: The Tangled Sky

Let us feel the pain first. Suppose we write the airport code in the "naive" way, where every flight knows about every other flight.

// ❌ BAD: every flight knows about other flights directly
class Flight {
  constructor(public name: string) {}
 
  otherFlights: Flight[] = [];
  isLandingNow = false;
 
  requestLanding() {
    // This flight must personally ask EVERY other flight!
    for (const other of this.otherFlights) {
      if (other.isLandingNow) {
        console.log(`${this.name}: Oh no, ${other.name} is landing. I must wait.`);
        return;
      }
    }
    console.log(`${this.name}: Nobody told me to stop, so I am landing!`);
  }
}

What is wrong here? Many things, and each one is a real bug waiting to happen.

• Every flight must keep a list of every other flight. When a new flight enters the sky, we must update all the existing flights. That is like every pilot writing down the phone numbers of fifty other pilots in mid-air.
• The rules are scattered. The rule "only one plane can use the runway" is hidden inside the Flight class. If we add a second runway tomorrow, we must edit every flight. If we add a VIP priority rule, again every flight.
• Nothing is reusable. A Flight that knows about these particular other flights cannot be reused at Mumbai airport. It is glued to Delhi.
• It grows out of control. Connections explode as planes increase. We will count this explosion with actual numbers in a minute.

Look at the two shapes side by side. On the left, the mess. On the right, the star.

Count the lines yourself. The web on the left has 6 wires for just 4 planes. The star on the right has only 4 wires — one per plane — no matter how complicated the rules become. All the complicated rules now live in one readable place: the tower.

College corner: here is the exact mathematics. In a system of n components where anyone may talk to anyone, the communication graph is a complete graph. The number of undirected edges in a complete graph is n(n-1)/2. For 4 planes that is 4 × 3 / 2 = 6. For 10 planes it is 45. For 50 planes it is 1,225. The growth is quadratic — in Big-O terms, O(n²) possible communication paths, and O(n²) places where a rule can hide. The mediator converts this complete graph into a star graph, which has exactly n edges — linear, O(n). You did not make the problem disappear; you changed its topology from "everyone wired to everyone" to "everyone wired to one hub". That single change is why the pattern scales.

Counting the Wires 📈

Numbers convince better than words. Here is the wire count as the sky gets busier:

Notice the first row. With 3 planes, the mediator saves nothing — both shapes need 3 wires. This is an honest and important point: the mediator pays off only when the group grows. For tiny systems, it is extra ceremony.

Now watch the two curves race:

The top curve is the spider web. The bottom line is Vikram's star. By 12 planes, the web needs 66 wires and the star needs 12. Every extra wire is a place where a bug can sit quietly for months.

The same explosion appears in everyday code too, far away from airports. Think of a sign-up form. The "country" dropdown must re-check the PIN code field. The "ship to another address" checkbox must reveal a hidden address box. The Submit button must stay disabled until everything is valid. If each widget pokes the other widgets directly, you get the same spider web, just smaller. A form dialog acting as mediator fixes it the same way the tower fixes the sky.

How One Landing Happens, Step by Step

Here is the recipe. Follow these six steps whenever you apply the pattern.

1. Spot the tangle. Find a group of objects that call each other directly in many directions — form widgets, chat users, planes.
2. Declare the mediator interface. Usually one method is enough: notify(sender, event). The sender says who is speaking; the event says what happened.
3. Build the concrete mediator. Give it fields that point to all the components it manages. Often the mediator even creates those components.
4. Give every component a mediator reference. Pass it in the constructor or with a setter. Components should depend only on the small mediator interface.
5. Replace direct calls with notifications. Wherever component A used to reach into component B, A now simply says mediator.notify(this, "something happened").
6. Put all coordination logic inside the mediator. Its notify method looks at the sender and the event, and then commands the right components.

Now watch Meera's landing request travel through the system, message by message:

Notice the beautiful thing: Meera never sends a single message to Arjun. The tower receives, thinks, and commands. If tomorrow we add twenty more planes, Meera's cockpit procedures do not change at all. She still does exactly two things: ask the tower, obey the tower.

And here is the same evening from the humans' point of view — the feelings, not just the messages:

Look at Arjun's score of 3 in the middle. Being told to "hold position" is mildly annoying — that is honest. The mediator does not make everyone instantly happy; it makes everyone safe and coordinated, which matters far more.

The Blueprint 📐

Before we write the full program, here is the class structure every Mediator implementation follows. This is the diagram you will draw in exams and interviews:

Read the arrows carefully. Flight points at the interface ControlTower, not at the concrete DelhiTower. That means tomorrow we can swap in a MumbaiTower with totally different rules, and the Flight class will not even notice. Meanwhile DelhiTower points back at flights so it can command them. There is no arrow from Flight to Flight. That missing arrow is the whole pattern.

Each plane, from the tower's point of view, also moves through a small set of states. The tower's job is really to manage these state changes safely:

A plane never moves itself from Holding to Landing. Only a tower instruction does that. In code terms: a component never changes shared state on its own; it asks the mediator, and the mediator changes the state.

Real Code: Building Vikram's Tower in TypeScript

Now let us build the Delhi airport properly, with the Mediator pattern. Read the comments — they carry the story.

// --- Step 1: The Mediator interface (the radio frequency) ---
interface ControlTower {
  notify(sender: Flight, event: string): void;
}
 
// --- Step 2: The Component ---
// Every flight knows ONLY the tower. Never another flight.
class Flight {
  constructor(
    public readonly name: string,
    private tower: ControlTower
  ) {}
 
  // The pilot presses a button: "I want to land."
  requestLanding(): void {
    console.log(`${this.name} (pilot): Tower, requesting permission to land.`);
    this.tower.notify(this, "request-landing");
  }
 
  // The tower may call these methods on the flight:
  land(): void {
    console.log(`${this.name}: Landing now. Touchdown! 🛬`);
    this.tower.notify(this, "landed");
  }
 
  hold(): void {
    console.log(`${this.name}: Holding in the air, circling patiently.`);
  }
}
 
// --- Step 3: The Concrete Mediator (Vikram in the Delhi tower) ---
class DelhiTower implements ControlTower {
  private runwayFree = true;           // only the tower knows the runway state
  private waitingQueue: Flight[] = []; // only the tower manages the queue
 
  notify(sender: Flight, event: string): void {
    if (event === "request-landing") {
      if (this.runwayFree) {
        this.runwayFree = false;
        console.log(`Tower: ${sender.name}, you are cleared to land on runway 29.`);
        sender.land();
      } else {
        console.log(`Tower: ${sender.name}, runway busy. Hold at 3000 feet.`);
        this.waitingQueue.push(sender);
        sender.hold();
      }
    }
 
    if (event === "landed") {
      console.log(`Tower: ${sender.name} has landed safely. Runway is free.`);
      this.runwayFree = true;
 
      // The tower decides who goes next. The flights never argue.
      const next = this.waitingQueue.shift();
      if (next) {
        console.log(`Tower: ${next.name}, your turn now.`);
        next.requestLanding();
      }
    }
  }
}
 
// --- Step 4: Wire everything and run the rainy evening ---
const tower = new DelhiTower();
 
const meera = new Flight("IndiGo 6E-202", tower);
const arjun = new Flight("Air India 145", tower);
const divya = new Flight("Vistara UK-995", tower);
 
meera.requestLanding();
arjun.requestLanding();
divya.requestLanding();

Run this, and the output tells the whole airport drama:

IndiGo 6E-202 (pilot): Tower, requesting permission to land.
Tower: IndiGo 6E-202, you are cleared to land on runway 29.
IndiGo 6E-202: Landing now. Touchdown! 🛬
Tower: IndiGo 6E-202 has landed safely. Runway is free.
Air India 145 (pilot): Tower, requesting permission to land.
Tower: Air India 145, you are cleared to land on runway 29.
Air India 145: Landing now. Touchdown! 🛬
Tower: Air India 145 has landed safely. Runway is free.
Vistara UK-995 (pilot): Tower, requesting permission to land.
Tower: Vistara UK-995, you are cleared to land on runway 29.
Vistara UK-995: Landing now. Touchdown! 🛬
Tower: Vistara UK-995 has landed safely. Runway is free.

Stop and admire three things:

1. The Flight class has zero references to other flights. You can copy-paste it into a Mumbai airport project tomorrow morning.
2. All the rules — runway status, the waiting queue, who goes next — sit in one class, DelhiTower. You can read the whole "traffic protocol" top to bottom in thirty seconds.
3. Want a second runway? Edit only the tower. Want a VIP priority queue for low-fuel planes like Meera's? Edit only the tower. The flights never change.

The Same Idea in C# — and the Famous MediatR Library

C# developers use this pattern every single day, often through a library called MediatR. But first, the plain pattern, short and sweet:

// The mediator contract
public interface IControlTower
{
    void Notify(Flight sender, string evt);
}
 
// The component — knows only the tower
public class Flight
{
    private readonly IControlTower _tower;
    public string Name { get; }
 
    public Flight(string name, IControlTower tower)
    {
        Name = name;
        _tower = tower;
    }
 
    public void RequestLanding()
    {
        Console.WriteLine($"{Name}: Tower, requesting landing.");
        _tower.Notify(this, "request-landing");
    }
 
    public void Land() => Console.WriteLine($"{Name}: Landing. Touchdown!");
    public void Hold() => Console.WriteLine($"{Name}: Holding position.");
}
 
// The concrete mediator
public class DelhiTower : IControlTower
{
    private bool _runwayFree = true;
    private readonly Queue<Flight> _waiting = new();
 
    public void Notify(Flight sender, string evt)
    {
        if (evt == "request-landing" && _runwayFree)
        {
            _runwayFree = false;
            Console.WriteLine($"Tower: {sender.Name}, cleared to land.");
            sender.Land();
            _runwayFree = true;
            if (_waiting.Count > 0) Notify(_waiting.Dequeue(), "request-landing");
        }
        else if (evt == "request-landing")
        {
            Console.WriteLine($"Tower: {sender.Name}, hold position.");
            _waiting.Enqueue(sender);
            sender.Hold();
        }
    }
}

In real .NET projects, the MediatR library by Jimmy Bogard applies the same idea to whole applications. A web controller does not call a service class directly. It sends a request object to the mediator, and the mediator finds the one handler that knows what to do:

// The controller does not know WHO will handle this. Only the mediator knows.
var result = await _mediator.Send(new BookFlightCommand("Delhi", "Chennai"));

The controller and the handler never meet. They are like two pilots who only know the tower. This is why MediatR became one of the most downloaded packages in the whole .NET world, especially in CQRS designs where commands and queries flow through the mediator to their handlers, keeping controllers thin and clean.

And to complete the set, here is the heart of the pattern in Python — notice how the shape stays identical even though the language changes:

# The mediator owns the rules; the flights own only their radios.
class DelhiTower:
    def __init__(self):
        self.runway_free = True
        self.waiting = []
 
    def notify(self, sender, event):
        if event == "request-landing":
            if self.runway_free:
                self.runway_free = False
                print(f"Tower: {sender.name}, cleared to land.")
                sender.land()
            else:
                print(f"Tower: {sender.name}, hold position.")
                self.waiting.append(sender)
        elif event == "landed":
            self.runway_free = True
            if self.waiting:
                self.notify(self.waiting.pop(0), "request-landing")
 
 
class Flight:
    def __init__(self, name, tower):
        self.name = name
        self.tower = tower   # the ONLY reference a flight holds
 
    def request_landing(self):
        print(f"{self.name}: Tower, requesting landing.")
        self.tower.notify(self, "request-landing")
 
    def land(self):
        print(f"{self.name}: Touchdown!")
        self.tower.notify(self, "landed")
 
 
tower = DelhiTower()
meera = Flight("IndiGo 6E-202", tower)
arjun = Flight("Air India 145", tower)
meera.request_landing()
arjun.request_landing()

Three languages, one shape: components hold a single reference, the mediator holds the brain.

Where Does the Logic Live? 🧠

A question students ask: "Did the complexity actually reduce, or did it just move?" Honest answer: it moved and concentrated — and that is the win. Scattered logic in twenty files is unfixable; concentrated logic in one file is readable. Here is roughly where the coordination knowledge sits after applying the pattern:

The 80 percent slice is the point. Before the pattern, that same 80 percent was smeared across every plane class, duplicated and slightly different in each. Now Vikram's notebook holds it all.

College corner: this concentration is exactly the Single Responsibility Principle applied at system level. Each Flight has one reason to change: flying behaviour. The DelhiTower has one reason to change: coordination policy. Compare this with the naive design, where adding one policy ("low-fuel planes jump the queue") forced edits in n component classes — an O(n) change cost per policy. With the mediator, every policy change is O(1) classes touched. The trade-off you accept is a single point of complexity (and in distributed systems, a single point of failure) at the hub.

Should You Use It Here? A Decision Picture

Not every project needs a tower. Two planes flying once a day can just look out of the window. Use this quadrant to place your own situation:

And the same decision as a table you can scan in ten seconds:

Where You See It in Real Software

This pattern is not a school-only toy. It runs the real world.

• Chat servers and group chats. In a WhatsApp group, you do not send your message separately to all 50 members. You send one message to the server, and the server delivers it to everyone. The server is the mediator. Many tutorials use a chat room as the classic mediator example for exactly this reason.
• MediatR in .NET. Used in thousands of companies; controllers send commands, the mediator routes them to handlers, and the two never import each other.
• Air traffic control systems. Real ATC software literally is a mediator: aircraft, radar feeds and ground vehicles all coordinate through one central system, never directly. Our story is not a metaphor — it is the actual architecture.
• UI dialog boxes. In GUI frameworks, a dialog window often acts as a mediator for its buttons, text boxes and checkboxes. The "OK" button does not disable itself; the dialog watches all fields and decides.
• Open-source examples. The java-design-patterns repository by iluwatar has a complete runnable mediator example, and Refactoring Guru shows it in ten languages.

Common Mistakes Students Make ⚠️

Two more small ones:

• Putting business logic of a component inside the mediator. The tower decides who lands when. It does not fly the plane. Keep each component's own work inside the component; the mediator only coordinates.
• Making the mediator interface too fat. Start with a single notify(sender, event). Add named methods only when events become truly different from each other.

Compare With the Cousins

Students often mix up Mediator with Observer and Facade. Here is the family photo:

One more interesting fact: a mediator is often built using Observer. Instead of components calling mediator.notify() directly, the mediator can subscribe to events that the components publish. The test to decide which pattern you are looking at: does one central object own the coordination rules? If yes, it is a mediator at heart, whatever machinery it uses inside.

College corner: in distributed systems this same trade-off appears as choreography versus orchestration. Microservices that emit events and react to each other are choreographed (observer-like, no centre). Microservices driven by one workflow engine are orchestrated (mediator-like, central brain). Neither is always right: orchestration gives you one readable flow and one bottleneck; choreography gives you resilience and a debugging nightmare. The n(n-1)/2 versus n argument scales all the way up from classroom code to cloud architecture.

The Whole Pattern in One Picture 🗺️

Quick Revision Box

+--------------------------------------------------------------+
|                  MEDIATOR — QUICK REVISION                   |
+--------------------------------------------------------------+
| What     : Objects stop calling each other; all talk goes    |
|            through ONE central mediator.                     |
| Picture  : Air traffic control tower + planes (a star).      |
| Parts    : Mediator interface, Concrete Mediator,            |
|            Components (know ONLY the mediator).              |
| Key call : mediator.notify(sender, event)                    |
| Maths    : edges drop from n(n-1)/2 to n.                    |
| Wins     : Loose coupling, rules in one place, reusable      |
|            components, easy to add new components.           |
| Danger   : Mediator can grow into a God Object — split it!   |
| Cousins  : Observer = one-way broadcast;                     |
|            Facade   = one-way simple door.                   |
| Used in  : Chat servers, MediatR (.NET), ATC software,       |
|            UI dialogs.                                       |
+--------------------------------------------------------------+

Practice Exercises ✏️

Try these yourself. Start from the TypeScript airport code above.

1. Two runways. Give DelhiTower two runways instead of one. The tower should send a plane to whichever runway is free, and queue the plane only when both are busy. Notice that you change only the tower — not one line of Flight. Feel the power of the pattern.

2. Low-fuel priority. Captain Meera's flight is low on fuel. Add an event "request-landing-urgent". The tower must put urgent planes at the front of the waiting queue. Again: count how many classes you edited. The answer should be one.

3. Classroom monitor. Build a Classroom mediator. Components: Student objects and one Teacher object. A student never speaks to the teacher directly; the student tells the class monitor (mediator.notify(student, "doubt")), and the monitor decides whether to forward the doubt to the teacher now or queue it for the doubt-clearing period. Print the full conversation.

4. Smart form (challenge). Create a SignupDialog mediator with three components: CountryDropdown, PinCodeField and SubmitButton. Rules: when the country changes, the PIN code must be re-checked (Indian PIN codes have 6 digits); the Submit button stays disabled until the PIN code is valid. All rules must live inside the dialog. Then add a fourth component — a "ship to another address" checkbox that reveals a second address field — and check how many existing classes you had to edit. If the answer is "only the mediator", you have mastered the pattern.

5. Maths check (college). For a system of 30 components, calculate the maximum direct connections using n(n-1)/2, then the mediator-star count. Write one sentence on why the difference matters more for testing than for writing the code. (Hint: every connection is a path a test must cover.)