EDA
(Event-Driven Architecture)

Introduction

You’ve heard the term, assumed it’s a buzzword, and now want to know more. What is event-driven architecture and how can it help you? How is it different from message-driven architecture? Can it help your domain? Read on to learn more about event-driven architecture.

Event-Driven architecture and Message-driven architecture are both excellent when you want to start deconstructing a monolithic architecture to create something more scalable and de-coupled. By breaking your system down into individual areas you create resiliency in the system and allow room to grow.

What is event driven architecture (EDA)?

Event-driven architecture is a software architecture paradigm that considers the individual messages of a network of services to be events, rather than requests. Everything to do with those events (the writing, reading, processing, and storage) is the main concern of the system. It is a concept for a system, rather than a new language that needs to be learned. You may need to use new software for event-driven architecture. 

Events can be considered as “named state changes”; a significant change in the state within the software or hardware. Events can be anything, depending on the domain; a keystroke, a text box filled, a form submitted, or a purchase made. Events can also come from external sources: stock items received, new purchases made, new users added, etc.

Event-driven architecture is usually split into event consumers and event producers. The two are usually independent: The event producers don’t know what the consumers are, and vice versa. 

Event producers detect that an event has happened and broadcast it as a message for consumers through event channels or streams. An event processing platform can then process this asynchronously. The consumers can either act on this event, or just be informed about it, depending on the functions of that consumer. The event processing platform can execute the response to the event, and send this down the stream to further consumers.

Event-driven architecture also allows for loosely-coupled or de-coupled applications. De-coupled or loosely-coupled applications don’t have to know where the events are sent to or where they come from. Like two apples growing on different branches of a tree; they aren’t aware the other exists or how they are consuming nutrients. 

Event-driven architecture is constructed in such a way that events are moved around the system, and are stored in databases. A key benefit to storing data as events is that the context for each business decision is stored with the event. It is the difference between asking “what is the share price of a company now?” and “how has share price changed over the past month and why?”: the second question includes an explicit request for the context with the information needed.

Give me an example of event-driven architecture

A very general example would be turning on your television. You pick up the remote control and press the button, which is the ‘event’. The remote control registers this event, sends a signal to the television to turn on and start the operating system. The remote control doesn’t know if the television turned on, only that the event is sent to the event listener, the television.

Event-driven architecture is an architecture where the currency of the system is ‘events’, rather than data. Events are always referred to in the past tense and represent a specific business fact. With a past-tense, specific name for an event such as ‘InvoiceIssued’, along with metadata (including a unique identifier for the event and a time stamp), events can become the building blocks for a loosely-coupled, highly scalable system that is suitable for any industry. 

What is message-driven architecture?

Message-driven architecture is a system where there are separate systems connected together by one messaging system. A message is a certain set of data, delivered to its intended destination. The messages need to contain certain points of information (Alan Kay suggested a message should contain: the identity of the object that receives the call, the code to be executed by the recipient, arguments for the code, and the return value). The call is sent to a designated function, the result is waited for, then acted upon. It’s a structure familiar to those starting out in the software industry.

The main difference between event-driven and message-driven systems is that a message is sent to a pre-determined location, whereas an event is broadcast to any potential listeners. Messages are stored in a queue and are then processed (and usually deleted) once, by a single, predefined consumer.

They are less complex than event-driven systems; if your system has communications that occur in a one-to-one manner, then message driven is a good approach. However, there is a limit to the complexity message-driven systems are capable of; with messages needing to know the recipients before they are sent and having to wait for a response, any system that is required to have a certain degree of complexity will struggle under the weight of the messages. If the message carrier is suitably sophisticated, then the system may be able to handle more complexity.

Give me an example of message-driven architecture

Consider your pet dog, wanting to be let outside. The dog may bark at the door for your attention, and will not stop until they have a response from you. Once you have opened the door, the dog can go outside and the barking stops. The barking is the message, and you are the recipient.

If you have separate applications that need to receive messages from each other, then a message queue would be a great solution to consider. As long as the message does not require an immediate response, a message queue can be a great start for an asynchronous communications protocol. 

When to use event-driven architecture

Event-Driven architecture is best suited for situations when you need to capture real-world behavior and the digital context around it and store it for future use. Consider a website with a shopping basket, where a customer adds items for purchase to the basket, then removes one, then purchases the remaining contents of the basket. Knowing the final state of the basket is valuable now because it will tell you how much money the customer has spent. Knowing the events that lead to the check out (adding and removing items from the basket) will help in the future, providing you with useful data to analyze on customer behavior. 

If there is a situation where you require context to be stored with data, then event-driven architecture would be an excellent solution for you. If the situation requires that a message is sent to only one recipient then a message-driven architecture would be better.

There is an evolutionary line from Xerox’s Star Computer in 1975, one of the first to use event-driven technology, through to The Gartner report of 2020 and the multiexperience. Although event-driven technology has been around for almost 50 years, it’s not yet had its moment in the spotlight. It could be argued that this is because user demand has never been nuanced enough to require the potential of event-driven systems and accessing information from multiple sources. 

Now that customers have real-time data and experiences, they won’t accept a downgrade; this will become the minimum standard. Gartner noted the potential of mature event-driven architecture back in 2019. Providing users with real-time information about their systems across multiple platforms make events extremely valuable for decision-makers. Event-driven architecture is not the solution to every problem, but it is an incredibly powerful tool for modern systems. Building your system with event-driven architecture will not only offer you a distinct advantage over your competition, but it will also keep up with your customer’s demands.

Event-driven architecture and distributed systems / DDD

Using event-driven architecture can deliver amazing benefits to wider systems. By using event-driven architecture within a distributed system to create highly scalable, flexible, and performant systems. It can be used with other concepts such as CQRS and Event Sourcing. 

An important point to make is that these concepts do not need to be used together. You don’t need to use an event database inside a distributed system with event-driven architecture. It’s just that these work well together. They are all part of a wider ecosystem of technologies that can work together very effectively.

Conclusion

Event-driven architecture and message-driven architecture are both excellent when you want to start deconstructing a monolithic architecture to create something more scalable and de-coupled. By breaking your system down into individual areas you create resiliency in the system and allow room to grow. Which you choose will come down to how much you want your system to grow. With a message-driven system, you are limited by the capabilities of the messaging platform chosen. With events as the foundation of your architecture, you’re only limited by the events of your customers.