Table of Contents
Event-driven architecture (EDA) is a design pattern built around the production, detection, and reaction to events that take place in time. It is a design paradigm normalized for dynamic, asynchronous, process-oriented contexts. Event-driven architecture enables minimal coupling, which makes it a good option for modern, distributed application architectures. And in this article, you will find key event-driven architecture benefits and considerations that will help you make the right decision.
EDA focuses on the generation and handling of event notifications. This concept defines strongly flexible architectures, in which the elements generating event notifications do not need to know the receiver components. In addition to that, an event-driven architecture has not a deterministic response time for processing input events, but it is much faster adapting to changes. This paradigm makes possible to create real-time responsive architectures. Event notifications imply modifications in the current state of the system. Notifications can be triggered by external sources such as user inputs, or needs of the market. However, there are also internal notifications of events, such as data sending for the pipeline work-chain, multicast of parameters for heterogeneous processing, internal triggers for certain services and generation of outputs. In the end, events can be understood as something similar to messages between different modules of the system, containing relevant information for the general and particular functioning of the system and its services.
An event-driven architecture uses events to trigger and communicate between decoupled services and is common in modern applications built with microservices. An event is a change in state, or an update, like an item being placed in a shopping cart on an e-commerce website. Events can either carry the state (the item purchased, its price, and a delivery address) or events can be identifiers (a notification that an order was shipped).
An event-driven architecture consists primarily of event creators, event managers, and event consumers. The event creator, which is the source of the event, only knows that the event has occurred and broadcasts a signal to indicate so. An event manager functions as intermediary managing events. Consumers are entities that need to know the event has occurred and typically subscribe to some type of event manager.
To understand it better, let’s look at a very good example: an online accommodation service where event creators ( property owners) broadcast the availability of their accommodation to the event manager (the online platform), which would aggregate these, and event consumers (people looking for accommodation) could subscribe to the platform’s mailing list sending them notifications for any new relevant listings.
One of the main event-driven architecture benefits is that it enables large numbers of creators and consumers to exchange status and response information in near real-time.
Many famous companies work with EDA, for example, Uber, Deliveroo, Monzo Bank or Centrica among others. All of them share a smart use of real-time information provided by the customers, IoT networks, and movements in the market.
Event-driven architecture models
An event driven architecture may be based on either a pub/sub model or an event stream model.
Pub/sub model
This is a messaging infrastructure based on subscriptions to an event stream, keeps track of subscriptions. With this model, after an event occurs, or is published, it is sent to subscribers that need to be informed.
Event streaming model
With an event streaming model, events are written to a log. Event consumers don’t subscribe to an event stream. Instead, they can read from any part of the stream and can join the stream at any time.
Event-Driven Architecture benefits
- Event-based architectures are asynchronous without blocking. This allows resources to move freely to the next task once their unit of work is complete, without worrying about what happened before or will happen next.
- Services don’t need knowledge of, or dependencies on other services. When using events, services operate independently, without knowledge of other services, including their implementation details and transport protocol.
- Services under an event model can be updated, tested, and deployed independently and more easily.
- Since the services are decoupled under an event-driven architecture, and as services typically perform only one task, tracking down bottlenecks to a specific service, and scaling that service becomes easy.
- An event-driven architecture with a queue can recover lost work by “replaying” events from the past. This can be valuable to prevent data loss when a consumer needs to recover.
This pattern achieves high performance through its asynchronous capabilities, the ability to perform decoupled, parallel asynchronous operations outweighs the cost of queuing and dequeuing messages. - Scalability is naturally achieved in this pattern through highly independent and decoupled event processors. Each event processor can be scaled separately, allowing for fine-grained scalability.
- Real-time situational awareness means that business decisions, whether manual or automated, can be made using all of the available data that reflects the current state of the systems.
Conclusion: event-driven architecture benefits
Nowadays, many emerging companies use business models based on the On-Demand Economy. In addition to that, the acquisition of information is getting massive thanks to technological and sociological trends like social media and IoT. EDA is the natural paradigm for making use of this real-time information and designing flexible systems able to adapt to the changes.
However, event-driven architecture pattern is a relatively complex pattern to implement, primarily due to its asynchronous distributed nature. When implementing this pattern, you must address various distributed architecture issues, such as remote process availability, lack of responsiveness, and broker reconnection logic in the event of a broker or mediator failure.
One consideration to take into account when choosing this architecture pattern is the lack of atomic transactions for a single business process. Because event processor components are highly decoupled and distributed, it is very difficult to maintain a transactional unit of work across them. For this reason, when designing your application using this pattern, you must continuously think about which events can and can’t run independently and plan the granularity of your event processors accordingly. If you find that you need to split a single unit of work across event processors—that is, if you are using separate processors for something that should be an undivided transaction—this is probably not the right pattern for your application.
And if you are interested in knowing more about Event-driven architecture benefits, I highly recommend you to read “Event-Driven Architecture: How SOA Enables the Real-Time Enterprise: How SOA Enables the Real-Time Enterprise” book by Hugh Taylor.
