We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Microservices Architecture
Free preview: the first 2 parts of this 6-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Microservices Architecture
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
Imagine an airport with no air traffic control tower. Every pilot talks directly to every other pilot. "Hey Flight 302, I'm landing on runway 2." "Wait, Flight 158, I'm already approaching runway 2!" With 50 planes in the air, that is 50 x 49 = 2,450 potential communication channels. Pure chaos.
Now add an air traffic controller. Every pilot talks only to the tower, and the tower coordinates everyone. 50 planes means 50 communication channels, one per plane to the tower. The tower knows the full picture and prevents conflicts.
This is the Mediator pattern. When you have N objects that need to communicate with each other, instead of N*(N-1) direct connections, you introduce a mediator that sits in the middle. Every object talks to the mediator, and the mediator routes messages to the right recipients.
Redux is a Mediator. Components do not talk to each other directly. They dispatch actions to the store (the mediator), and the store notifies the right components. RabbitMQ is a Mediator. Producers publish to exchanges, consumers subscribe to queues, and the broker routes messages based on binding rules. ' etcd plus the controller manager is a Mediator. Every controller writes desired state to etcd, and the controller manager reconciles actual state against it.
The Mediator pattern defines an object that encapsulates how a set of objects interact. It promotes loose coupling by keeping objects from referring to each other explicitly.
| Without Mediator | With Mediator |
|---|---|
| Component A calls B, C, D directly | Component A sends message to Mediator |
| Component B calls A, C, E directly | Mediator routes to B, C, or whoever needs it |
| Adding Component F means updating A, B, C, D, E | Adding Component F means registering it with Mediator |
| N objects = N*(N-1) dependencies | N objects = N dependencies (each to mediator) |
| Debugging: trace calls across N services | Debugging: look at the mediator's message log |
The mediator knows the routing rules. Components know nothing about each other. They only know the mediator's interface. This makes adding, removing, or replacing components trivial.
The math matters in practice. A system with 10 and direct point-to-point communication has up to 90 possible connections. Add an event bus (mediator) and you have 10 connections, one per service to the bus. When a team wants to add an 11th service, they register with the bus. Zero changes to the existing 10 services.