What Is a Broker - and Why It’s Never “Just a Pipe”

Now that we understand what an Event is, and how it differs from Polling, we need to stop at the component that usually hides in the middle - but is the one that actually decides how the system behaves.

That’s the Broker.

What a Broker Actually Is

A Broker is a mediating component: it receives events from whoever created them, and passes them on to whoever is supposed to receive them.

Seemingly - a simple role: receive → forward.

In practice - it’s one of the most influential components in an Event-driven system.

Why You Even Need a Broker

Without a Broker, the event’s creator needs to know:

• Who the consumers are
• How to reach them
• When they’re available

That creates direct dependency.

A Broker is meant to break that dependency:

• The creator doesn’t know who will respond
• The consumer doesn’t know who created it
• And each of them proceeds at their own pace

That’s the big advantage of Event-driven - but it’s not free.

A Broker Doesn’t Just Forward - It Decides

The moment you introduce a Broker, it starts making decisions:

• Whether to keep an event or drop it
• Whether to forward immediately or queue it
• Who to forward it to - and in what order
• What happens when a consumer is slow or goes down

Every such decision affects: Latency, load, stability, and the character of failure.

In other words: a Broker isn’t a pipe - it’s a control point.

Where Latency “Enters”

In a system without a Broker, time passes directly between creator and executor.

With a Broker, time splits:

• Time to reach the Broker
• Time waiting in queue
• Routing time
• Time until a consumer is free

None of these times is large on its own - but together they create significant Latency, and especially variable Latency.

And this loops back to what we already saw: Event-driven doesn’t eliminate time - it moves it into the mediation layer.

Why a Broker Changes the Nature of Failure

Without a Broker: failure is immediate and clear. If the destination isn’t available - everything stops.

With a Broker: failure can be silent:

• A queue lengthens
• Events pile up
• And the response is delayed without anyone “going down”

It looks like a working system - but in practice it’s losing control.

A good Broker doesn’t just forward events, it also defines what a malfunction looks like.

An Analogy

Imagine a mail sorting center.

Without a center: you hand a letter directly to the recipient. If they’re not home - you know immediately.

With a center: the letter is received, sorted, queued, and forwarded. You don’t know when it will arrive - and you also don’t know if it got stuck along the way.

The center doesn’t just move mail. It determines the waiting experience.

The Bottom Line

The Broker is the heart of an Event-driven system. Not because it’s smart, but because it’s on the path of everything.

It enables decoupling and scale, but it also:

• Adds Latency
• Changes load behavior
• And moves failures to places that are hard to see

And that’s why you can’t talk about Event-driven without understanding that the Broker isn’t a pipe - it’s a design decision.