What is Event-Driven Architecture (EDA)?

Our founders have shared a passion for designing and implementing event-driven architecture (EDA) throughout their careers as cloud & solution architects. They became convinced that EDA would become the de facto software architecture for companies willing to evolve.

Since it is still a relatively new concept at the moment, we would like to take this opportunity to give a general introduction of event-driven architecture. What is it about? Which purposes does it serve? How does it work in a real-life situation? Read on to find out more!

Introduction and definitions

Let’s set the stage by defining some components and how they interact. Event-driven architecture is a software paradigm in which services and applications communicate asynchronously through publishing and consuming events. An event is anything that happens in a business environment or their customers’ ecosystem.

Examples of events include an order being placed, an invoice being paid, an oil sensor signalling a change in temperature, an insurance claim being requested, … In other words: events can originate from both the business and technical sides of an organisation.

An event-driven architecture uses those business and technical events to communicate and distribute data across services and applications. It makes sure that events are distributed in real-time across the architecture as soon as they happen. That way, other applications and users in the architecture can handle or store event data as they see fit with as little lag as possible.

The applications and services that trigger events are called event producers. Producers know when certain events occur and publish them to show that they happened while including the relevant information.

The event hub receives the notifications sent out by producers and notify other parties that have registered their interest in receiving certain events. Those interested parties are called event consumers. They can be organised in consumer groups by the type of events they are interested in.

When users receive events, they can either trigger a new process based on the information they received, or store that information in the environment for future use. The event hub can also decide whether to save the event to an event log, sometimes called an event stream. It can then read and process part of those logs later.

How it works

The terminology above may seem somewhat abstract, so let’s illustrate how event-driven architecture works in reality. In this example, a customer buys an item through an e-commerce website. This is what happens next:

1. As soon as the customer finishes the buying process, the system generates an event called “item purchased”. This event contains all relevant information: the customer’s name, the item’s ID and amount, the pricing, shipping details, …
2. The system publishes the event to the event hub, which in turn notifies any event consumers that have marked their interest in a “item purchased” event.
3. One of those consumers is the inventory service. It consumes the event, which triggers a reservation action to mark the item in the website’s inventory.
   1. Meanwhile, the customer relationship management (CRM) application also consumes the event. It uses the enclosed information to update that customer’s sales and purchasing behaviour data. It stores the information, but takes no further action.
      
   2. At the same time, the hub also notifies the billing department, since it is part of the same consumer group. It uses the event information to create an invoice and send it to the customer.
      

As you can see in this example, one event can trigger multiple actions for several interested parties. Those services can all work asynchronously, which means that they do not have to wait for each other. In other words, the three parts of the third step above can happen simultaneously.

The advantages of using EDA

Using event-driven architecture has proven to have numerous benefits for both business and IT environments. An obvious advantage is that services can be decoupled because of the asynchronous communication. This means they no longer need to rely on each other for scaling and don’t impact other services in case of failure. Their development teams also no longer have to depend on each other to deploy new features or improve their service.

Working with events also makes real-time data processing possible from several sources: not just software applications and services, but all kinds of IoT devices as well. This lets organisations make more and quicker informed decisions, based on data they can trust. By increasing responsiveness, companies can innovate faster and set themselves apart from the competition.

We’ll discuss the different technologies that support EDA and to which models it can be applied in upcoming blog posts, so be sure to keep an eye on this space!

Want to know more about event-driven architecture and how it can help your organisation? Contact us, and we’ll be happy to help you out!