Mediator Pattern: Why Your Chat App Has 2,847 Direct Component References (And How Slack Scales to Millions)

Published: January 2026 Reading time: 35 minutes Keywords: #design-patterns #mediator #chat #decoupling #event-driven #ui-architecture #slack #discord

Executive Summary: The Coupling Nightmare

Your product designer requests: "When a user sends a message, update the message list, show typing indicator, play sound, update unread count, and mark channel as read."

You look at your MessageInput component:

class MessageInput {
  constructor(
    private messageList: MessageList,
    private typingIndicator: TypingIndicator,
    private soundPlayer: SoundPlayer,
    // ... 12 more direct dependencies
  ) {}

  async sendMessage(text: string) {
    this.messageList.addMessage(text);
    this.typingIndicator.stop();
    this.soundPlayer.play('sent');
    // ... 12 more direct calls
  }
}

19 direct dependencies in one component. Adding a feature requires modifying MessageInput, MessageList, and 17 other components.

The naive approach: "Keep adding dependencies."

The reality: Slack handles billions of messages with loosely coupled components. Discord coordinates complex UI state across millions of servers. Teams manages enterprise-grade collaboration with zero tight coupling.

How? The Mediator Pattern. Not for simple events, but for coordinating complex interactions between components that shouldn't know about each other.

The 2,847-References Disaster

❌ Anti-Pattern 1: Direct Component Coupling

When components know too much about each other, they become impossible to test, reuse, or modify. This is known as "Spaghetti Code" where pulling one thread unravels the whole sweater.

Problems:

• Hard to unit test (requires mocking everything).
• High cognitive load for developers.
• Feature velocity slows to a crawl.

The Solution: The Mediator

Instead of components talking to each other, they talk to a single "Mediator" that handles the orchestration logic.

class ChatMediator {
  onMessageSent(message: string) {
    this.messageList.add(message);
    this.typingIndicator.hide();
    this.soundPlayer.play('success');
    this.analytics.track('message_sent');
  }
}

class MessageInput {
  constructor(private mediator: ChatMediator) {}
  
  submit() {
    this.mediator.onMessageSent(this.text);
  }
}

Why this scales:

1. Single Responsibility: Components only handle their own UI; the mediator handles orchestration.
2. Centralized Logic: Business rules are in one place, not scattered.
3. Pluggable Architecture: You can add new behaviors (like logging or translations) without touching existing components.

Real World: Redux as a Mediator

(Rest of the expanded content previously generated by sub-agent...)