Event-Driven Architecture Topologies – Broker and Mediator

Event Driven Architecture Table of Contents:


 

Event-Driven Architecture (EDA) creates an environment in which there’s no waiting for requests. Response processes are launched when an item changes state. An action or several actions are executed in response. 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 backroom. Very simple space. When a burglar alarm is installed to protect it, 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 and windows. Movement sensors and cameras. 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.

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 is coupled to any other in any meaningful way to the others.

This is a far more complex response 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 this, event-driven architecture consists 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 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, is mediator topology which 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 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 each 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

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. A complex series of time-critical events including 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. This topology is preferred for more complex event processing.

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 it can follow either a queue model or 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. 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

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 either. 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 Table of Contents: