Broker and Mediator Topology

In a talk at the GIDS Architecture Live 2020 series, Neal Ford talks about application and distributed architectural styles, analyzed along several dimensions (type of partitioning, families of architectural characteristics, and so on). Watch his insights on Event-driven architectures and read an excerpt from the presentation.

Let me talk about two event-driven architectures briefly here, broker and mediator topology. Now, events and messages can be used and are quite often used within higher-level architectures, like microservices. And in fact, at the end of the day for you today, but tomorrow morning for me, I'm doing another talk called Architecture by Example, and it actually demonstrates using events inside microservices as a way to design an architecture, but you can also design an architecture purely just on top of events and messages.

And you still might want to do that, because it gives you the unique combination of both scalability and performance, and it's hard to get both of those at the same time. Now, you have to build a lot of the moving parts yourself in an architecture like this, but you do get some really interesting capabilities.

Broker Topology

So, let's talk about the two shapes of this architecture. And the first of these is the broker topology. And here you have an initiating event, just something that happens from the outside world. And that gets captured by an event channel, which then redirects that to an event processor, which is where code lives within this architecture.

And that unit processor will do some processing on it, as to its name, and then optionally post a message to another event channel, which will then do some processing on it, and post another message until this business process is complete. This is a good example in a broker of what's called choreography as a message passing style.

So, let's look at a complex business process in a broker typology. So, let's say for example, we're an insurance company and the initiating event is change of address for one of our customers, so our customer moves. Customer process will pick that up and do whatever internal update is necessary for that move and then post a message to anyone interested in a change of address. Turns out both quote and claims are interesting change of address, so they'll both pick that message up and, in parallel, they will process and do whatever they want to do with it until finally, this processing is done. Notice that claims may, in fact, multicast and send messages to multiple different end points.

And this is called choreography because there's no central ordination here. Each of these processes is just reacting to some event that happened before, and so adding, for example, a new event process is trivial here, because you just latch on to an existing event queue.

Mediator Topology

So, let's talk about the other topology, mediator. And it's worth saying parenthetically here that I said that these two give you the unique combination of performance and scalability, but one of these gives you higher performance and scalability, and I'll talk about why in a second. So, let's talk about the other one, the mediator topology. And this has the same basic building blocks we saw before: initiating event, any event queues and messages, but it has this extra piece called a mediator.

Now, realize this is an architecture, a style or pattern. It's not a particular tool, although lots and lots of different tools implement this mediator pattern. Enterprise service buses implement this, Apache Camel implements this, Spring WebFlux implements this; basically, any architectural component that allows you to define some workflow between distributed components, and that's a pretty broad category of things.

And so, in a mediated event-driven topology, you have this mediator and it's the one that accepts messages and sends out work to all these different processors. But you notice none of the internal event processors send messages to each other. They always go back through the event mediator.

And that's important because the important business workflows are defined in that mediator. And you don't want to accidentally bypass one of those by going around it for example. When you look at our complex business workflow here, it's much simpler to understand because you can write that down in your mediator.

Now, this is typically written in XML, or central workflow language, or maybe it's a B.P. tool or business process, execution language tool, or something like that. But it allows you to write down what order things get, what happened. And in fact, do things like pseudo-transactional coordination across these end points.

This is what's traditionally called orchestration and that process mediator is acting as the orchestrator. So, what's the distinguishing factor of an orchestra is the conductor standing up front, controlling the timing and coordination of everything, and that's exactly what a mediated event-driven architecture does.

Why would you build an architecture in all these very low-level moving parts? You notice I never mentioned a database here. If you want data, you have to wire that in yourself, any kind of behavior, like transactions all have to be hand coded in this architecture.

The reason you picked this architecture is a specific kind of modulator to get a high degree of agility and fault tolerance, mostly built into the tools, but also really, really good scalability and performance, And that's the real selling point of this architecture.

[highlights]Now, of the two topologies, broker or mediator, which do you think gives you higher degrees of performance and scalability?
Turns out broker is the champion here because you can do more things asynchronously and there's less coordination required than through something like a mediator, which always becomes a bottleneck, both from a technical standpoint and from a social standpoint, you'll end up with integration architects that start ruling your organization around that enterprise service bus, for example.[/highlights]

But of course, everything in software architecture is a tradeoff. That's actually the first law of software architecture from our book, everything in software architecture is a tradeoff, including this, because while you get better performance and scalability from broker, it's much more complex to deal with because everything's asynchronous, you get deadlocks and race conditions.

Debugging is really difficult, doing things like error handling and transactional coordination is very difficult. And so, generally you rely on higher level architectures like microservices, but very often you create hybrids. And in fact, you will often see a broker style, event-driven architecture being used in combination with microservices to solve some of the performance issues that you sometimes see in microservices, and we'll talk more about that as we talk about microservices.

You also get really good elasticity, adaptability and evolvability. Those last two may seem like the same thing, but they're not. Adaptability is the ability to keep existing behavior and then add more to it, whereas evolvability is the ability to fundamentally change over time, and this architecture supports both of those things very nicely.

Watch the full talk to gain a well-rounded understanding of the criteria required to judge the applicability of a problem domain to an architectural style.

Like This? Register for our Newsletter to Continue the Converstion

See Highlights of

Hear What Attendees Say

PWC Logo

“Once again Wurreka has knocked it out of the park with interesting speakers, engaging content and challenging ideas. No jetlag fog at all, which counts for how interesting the whole thing was."

Cybersecurity Lead, PwC

Intuit Logo

“Very much looking forward to next year. I will be keeping my eye out for the date so I can make sure I lock it in my calendar"

Software Engineering Specialist, Intuit

Groupon Logo

“Best conference I have ever been to with lots of insights and information on next generation technologies and those that are the need of the hour."

Software Architect, GroupOn

Hear What Speakers & Sponsors Say

Scot Davis

“Happy to meet everyone who came from near and far. Glad to know you've discovered some great lessons here, and glad you joined us for all the discoveries great and small."

Scott Davis, Web Architect & Principal Engineer, ThoughtWorks


“What a buzz! The events have been instrumental in bringing the whole software community together. There has been something for everyone from developers to architects to business to vendors. Thanks everyone!"

Voltaire Yap, Global Events Manager, Oracle Corp.

Venkat Subramaniam

“Wonderful set of conferences, well organized, fantastic speakers, and an amazingly interactive set of audience. Thanks for having me at the events!"

Dr. Venkat Subramaniam, Founder - Agile Developer Inc.