Event-Driven Architecture Topologies – Broker and Mediator

Event-Driven Architecture (EDA) creates an environment in which there’s no waiting for requests: Response processes are launched when an item changes state. And an action or several actions are executed in response.

The key advantages of EDA are that it is both asynchronous and distributed. Since events may trigger when resources are not available to respond to them, EDA also provides storage for such event notifications until resources become available in the form of an event queue.

Another advantage is that EDA is highly-decoupled. None of the event producers or consumers are aware of each other and remain so even after the transaction is completed.

Since EDA processes are highly-decoupled, they can be scaled independently, which makes it a good option for modern, distributed, and cloud-enabled applications that are horizontally scalable and resilient to failure. Given that EDA is made up of highly-decoupled, single-purpose, event-processing components that asynchronously receive and process events, it is also highly-adaptable and can be used for both small and large, complex applications.

Contending with Complexity

Burglar alarms serve as a useful metaphor here…imagine a small jewelry store with one general retail space and a back room—a very simple space. When a burglar alarm is installed to protect the store, sensors are placed on the doors and windows. When a robbery begins, the very first event is either the door being broken open or a window being smashed. Either of these events sets off the burglar alarm. A simple one-to-one relationship between the sensors and the alarm occurs.

Now imagine the burglar alarm system for Fort Knox…many more doors, windows, movement sensors, cameras, and other sensors most of us cannot even imagine. But only one of them must be tripped to create the event of a suspected break-in. And alarms are only the beginning of the response. Large steel doors throughout the complex drop into place. Open vaults automatically close. All cameras begin recording. Several people are contacted directly and alerted. All the lights go on.

Many, many things happen in response to that one event. This requires more sophisticated orchestration of the execution of many responses on many systems—none of which are coupled in any meaningful way to the others.

This is a far more complex response and appropriate for a much larger facility with greater needs. Both responses are commenced and coordinated using event-driven architecture. But two different ways of managing the response are needed to accommodate complex responses and simple ones.

Two Main EDA Topologies

To achieve complex responses, event-driven architectures consist of two main topologies: the mediator and the broker. The mediator topology is commonly used when you need to orchestrate multiple steps within an event through a central mediator, whereas the broker topology is used when you want to chain events and responses together directly without the need for a mediator. Because the architecture characteristics and implementation strategies differ between these two EDA topologies, it is important to understand each one to know which is best suited for your particular use case.

Mediator Topology

This event-driven architecture topology is better suited for more complex situations in which multiple steps are required to process an event, thus requiring event processing coordination or orchestration. Mediator topology consists of four main components: the queue, the mediator, the channels, and the processors.

An event sends a message through a pre-processing event channel to a single event queue, which will transport the event to the mediator—thus initiating an event stream that routes events to relevant event processors. Orchestration is performed by the mediator, sending asynchronous events to various event channels that will perform each individual step of the process. The event processors, meanwhile, are listening to the channels and receive the event from the mediator. They then perform the business logic required to process it.

The mediator transforms the initial event it receives by generating a processing event that can be received by the processors. This is not to say that the mediator itself performs any business logic. It simply provides processing instructions to the processor. All business logic processing for every single event is performed by the event processor containing the required application logic associated with that specific task. No other processors will be involved.

Mediator Topology Example

Often, when an event occurs, several processes must be called upon to execute, and not always at the same time. At Fort Knox, many things must happen instantly and some later on. These include a complex series of time-critical events such as alerts to enforcement personnel, shutting of emergency doors, lights coming on, and klaxons going off.

Follow-up reporting and analysis must happen and be confirmed later. This requires orchestration, making certain that all responses are properly processed by relevant processors. These event processors receive event notification from the mediator and perform the appropriate business logic.

Broker Topology

Broker topology is best suited when you have a simple event stream that doesn’t require event orchestration. No mediator is required, so it can be centralized.

Like an event stream in mediator topology, the topology can follow either a queueing model, a lightweight message topics model, or a combination of both. The only core components involved are the broker and the processors. The broker component is federated and contains event channels used within the event flow. This is a far simpler model, but it does support multi-channel communication, with each channel receiving its own identifier.

There is no event queue or mediator in broker topology; it depends upon the event processors to obtain each event, publish them, and process another event that announces the end of processing. Preserving the loosely-coupled nature of EDA, the tasks all remain asynchronous. When a task ends, a callback is triggered. This published message is not consumed by any other event, which may leave the application open for future updates.

Broker Topology Example

Simple event streams don’t require orchestration, so the broker topology better fits the need. In our jewelry store example, a breach of any of the security devices, such as breaking a window, creates an event that is sent directly to the broker. The broker communicates the event notification directly to the event processors. Since nothing is asynchronous, no event queue is required. At the end of each process, notification of completion is issued by the event processors.

Which EDA Topology Should You Choose?

While the choice of which EDA topology to use is seldom simple, the general rule is that broker topology will likely be your choice for simple, single events requiring one task as their result. A mediator is required when an event sets off multiple tasks in response, thus requiring significant coordination or orchestration.

Event-Driven Architecture is just one of the methods our product development teams use to drive your success. Contact 3Pillar Global today to learn how we can do it for you.

[adinserter name=”EDA Guide”]