𝐒𝐮𝐦𝐦𝐚𝐫𝐢𝐬𝐢𝐧𝐠 𝐄𝐯𝐞𝐧𝐭-𝐃𝐫𝐢𝐯𝐞𝐧 𝐀𝐫𝐜𝐡𝐢𝐭𝐞𝐜𝐭𝐮𝐫𝐞

An event-driven architecture is a distributed architecture comprising individually deployable components, each component acting as an event processor.

Topologies within event-driven architectures determine how event processor communication takes place and how control flow is established, two common topologies are the broker and mediator topologies:

𝐁𝐫𝐨𝐤𝐞𝐫: In this topology, the initiating event is picked up by a single event processor which performs some relevant action and then creates and broadcasts another event known as the processing event, the processing event contains details of actions performed on an event by an event processor.

Event processors listen to events of interest and ignore others however it is expected that a new processing event is created and broadcasted by each event processor that picks up an event of interest.

𝐌𝐞𝐝𝐢𝐚𝐭𝐨𝐫: This topology revolves around one or more mediators, initiating events are picked up by the mediator and it is in charge of orchestrating the event by controlling the workflow by passing events to relevant processors and acting on their responses

Identifying the trade-offs between these topologies will drive decision-making based on what are the most important characteristics for the concerned system/context.

The broker topology ranks highly on the extensibility characteristic as control flow can be simply expanded by the addition of event processors that hook onto existing events while the mediator topology would require the addition of a new processor as well as modifying the mediator to account for the new processer as part of its orchestration logic.

The mediator topology allows for fine-grained control flow such as error handling allowing for failed steps within the flow to be repeated while this is not possible within the mediator topology as control flow can prematurely end when a failure occurs within an event processor.

A hybrid approach can be adopted in the same system, some parts may utilize a broker topology while others may leverage a mediator, this allows for compensating the shortcomings of one topology over the other.

This architecture style is based on asynchronous communication styles however pseudo-synchronous techniques such as request-reply can be leveraged.

Major strengths of this architecture include performance due to parallelism where multiple types of processer can respond concurrently to the same event in different ways, Scalability is another strength of this style as event processors can be spun up on an ad-hoc basis.

Simplicity and testing suffer within this architecture, for example, parallelism makes it impossible to determine the order of operation, and topologies such as the broker topology make it difficult to determine at what point a workflow ends or diagnose failure.

Image credits go to "Foundations of Software Architecture" by Mark Richards & Neal Ford.