An event-driven architecture (EDA) is an architectural style based on the processing of events.
“Processing” in this context means the way in which we react to certain events. Each event represents a state change within a system, such as a change to a customer address.
This kind of architecture consists of independent components that communicate with each other via events, with each component receiving and processing data. Because communication is asynchronous, the components can be used and scaled flexibly and independently of each other.
This approach is suitable for both large and small applications and has the following advantages.
The individual components receive and process individual events. Communication between them takes place via an abstraction layer, through what’s called channels. As long as the data format of the events that are being exchanged remains stable, changes to one component won’t require any additional adjustments to other components.
New features can be added by adding new components without having to adapt existing components. The new components can also receive and process the data.
In an EDA, events are processed asynchronously, which means they can be processed in parallel or with a time delay during peak loads.
Components can be developed, expanded, and combined independently of each other, which allows functionality to be flexibly adapted, added, or removed.
Events can be processed directly, thus enabling the creation of what’s called reactive applications.
Communications between components can be implemented in an event-driven architecture with two topologies or patterns:
In the mediator topology, a central mediator or message processor controls the coordination and processing of events and thus orchestrates the message processing of the components. This approach is particularly suitable for more complex workflows within an application.
In the broker topology, on the other hand, events are distributed via a central event broker that is exclusively responsible for forwarding and distributing events. An event-driven architecture is often implemented with messaging technologies.
The orchestration of a process by a central mediator or process manager always makes sense if an event must be processed by multiple components in a more complex workflow.
For example, let’s say a customer triggers an order in an online store system, the central process manager can orchestrate the next steps, such as the following:
In our case, the sequence of individual steps and the dependencies between them can be decisive; for instance, shipping should only take place after successful payment. The process manager ensures that the individual steps are coordinated and executed correctly before the event is forwarded to other components.
The use of a central process manager or mediator is called the hub-and-spoke message flow pattern, which is shown in this figure.
In this pattern, a trigger message starts a new process within the process manager. The process manager then analyzes the message and uses the logic and rules it contains to determine which component should take over the processing. The process manager then redirects the message to the corresponding component. As soon as the component has completed its task, the component sends its response back to the process manager. Then, the process manager uses the message to decide which component should perform the next processing step and forwards the message accordingly.
The process manager does not execute its own business logic on the messages. Its sole task is to correctly forward messages to the loosely coupled, independent components that fulfill quite specific tasks.
A central process manager or mediator can either be implemented in-house, or you can use existing software products and libraries. Various commercial and open-source products are available for this purpose, such as the following:
The pros and cons of adopting a message processor include the following:
With the message broker topology, messages are also exchanged via a central point, called the message broker. However, the message broker does not contain any logic or rules for mapping a process; it is only responsible for message transfers between individual components. The corresponding logic for the message flow is distributed across the components involved.
In the message broker topology, the individual components process events and in turn generate events that reflect the result of the executed action, as shown in the next figure.
For example, when a customer triggers an order in an online store system, the shopping cart component generates the “New order” event and transmits it to the message broker. All components that are interested in this event receive the event and can process it. As a result, the validation component returns the “Order successfully validated” event and thus enables the next interested component to continue working. This process is repeated continuously until the order process is completed or no more components are interested.
The way this topology works can be compared to a relay race: Each component passes the event to the next component in the chain after it has processed it.
This topology is suitable for use cases in which only limited logic is required for message distribution and the central orchestration of the processes is not desired.
Some proven software products and libraries available for implementing a message broker topology include:
The pros and cons of adopting a message broker include the following:
Event-driven architecture offers a compelling approach to building modern software systems, striking a balance between flexibility, scalability, and maintainability. Choosing between the mediator and broker topologies ultimately comes down to the needs of your application: if your workflows are complex and require careful orchestration, a central process manager gives you the control to manage that complexity, while a message broker is better suited for simpler, more distributed logic. Like any architectural pattern, EDA is not a silver bullet, and teams should weigh the operational overhead carefully before committing. That said, for applications that demand real-time responsiveness, independent scalability, and the freedom to extend functionality without disrupting existing services, event-driven architecture remains one of the most powerful tools available to software architects today.
Editor’s note: This post has been adapted from a section of the book Software Architecture and Design: The Practical Guide to Design Patterns by Kristian Köhler. Kristian is a software architect and developer with a passion for solving problems using efficient, well-structured software. He is the managing director of Source Fellows GmbH.
This post was originally published 4/2026.