Event-Driven Architecture: An integration pattern that literally saves lives

Event-Driven Architecture (EDA) is a commonly used architecture pattern in many modern applications and microservice-based approaches. More applications adapt to this type of architecture strategy as it provides more opportunities for integration and scalability. Especially when you want to integrate your software system to other systems (3rd party systems), event-driven architecture can be a crucial player to your system.

EDA can also be seen as an integration pattern that responds to an event created in a system, allowing other consumers (3rd party applications) to “subscribe” to this event and take action.

According to Gartner, 80% of digital business solutions in 2020 will be based on real-time characteristics, requiring support for event-processing. In this article, we’ll discuss how EDA works and how it allows for better integration between systems.

What are the characteristics of Event-Driven Architecture?

• It’s a one-way “fire and forget” approach
• It facilitates immediate action for consumers
• It’s informational (not commanding)

How does Event-Driven Architecture work?

The event emitter produces an event and represents it as a message. This message is transmitted to one or more event consumers through an event transporter or broker (event bus). The event consumer may have its system that processes the events to trigger another action.

Think about a fire alarm system in your building. Fire sensors detect smoke and send a message to the dispatcher or alarm management system. The alarm system might send a message to the owner and, at the same trigger the fire alarm. Later the owner decides to buy another third-party device, which automatically notifies the fire department. The new device does not have to know about how the sensors or the data works. It does not need to know any information but to subscribe to the “Smoke Detected” event.

The great thing about EDA is that it can be integrated with other services across simple and complex platforms.

Car Fuel Level Sensors

Your car’s sensor will continuously monitor the level of fuel in your gas tank until it hits a certain level. Once it does, the new condition triggers a notification in the system. The event consumer can receive this data and indicate to the driver via a blinking light that the tank needs to be filled up. Imagine you would have to gauge your tank level…

If a system knows how to subscribe to this event, it can, for example, send a message to you indicating the nearest fuel station around you. Some car rental companies use these events to integrate automatic rental and payment systems in the cards. One of the best examples is Socar, which also shows the fuel level in the App! Or after finishing the ride, they send you immediately the number of kilometres you drove. You already know how they collect the information 😊

E-Commerce App

Let’s imagine a user has just opened an e-commerce app and clicked on one of the advertisements. This event can be consumed by a promotion engine, in this case, the subscriber. Based on this event, one of the subscribers can be a promotion engine and calculates recommended products and promotional content for the active user and send it via email.

More complex platforms…

Earthquakes or volcano eruption detection algorithms are perfect examples of more complex event-driven architecture systems. They will use multiple variables set in place to detect that an earthquake or an eruption is happening. Literally, an absolute lifesaver!

What pain point does Event-Driven Architecture solve?

For many companies, traditional architectures just can’t handle the amount of incoming data they collect, especially in real-time or on at massive scale. It becomes increasingly difficult for companies to manage the data they continuously generate.

And so…

EDA is the perfect fit to this because it enables systems to accept a tremendous amount of incoming data or events and this leads to a nice horizontally scalable solution, where you add parts to the system to increase its capacity. This makes software systems more resilient to failure.

Many applications that look well-structured on the surface do not always have great infrastructure performance capabilities. This could affect your progress. The popularity in EDA has since surged as it allows companies to move faster to deliver a scalable solution.

3 major advantages of Event-Driven Architecture

1. Resilience due to the true decoupling of producers and consumers

As one component is decoupled from the next, an EDA means that one part of the system does not have to worry about the health or status of another. The application itself is still able to run, even if one part of the system is brought down. This decoupling offers a high level of resilience.

2. Opportunities for Integration & Expendability

The producer of the event does not need to know about the subscribers that consume the event. On the other hand, consumers of the service only need to subscribe to the event stream. Many third applications can be easily coupled to an event without having to completely mirror their own system to the producer.

3. Testing of new components is independently possible

If you want to create a new component to your structure based on an event, you can do so without affecting other parts of the system. We can do this through complete isolation of components which can mean keeping one part of the system offline and others online.

Things you need to look out for before implementing EDA

Debugging can be difficult.

You can’t debug microservices in the same way you’d debug a monolith. Truth be told, debugging, and troubleshooting can be a nightmare. You’ll have to map out every event that has been sent in a specific chain to really find the bug that needs to be fixed. Logging is distributed across each event, and the flow can’t be easily followed through code.

For that reason, in event-based architecture, the test manager plays a significant role in designing the test scenario. Testing with an external system is difficult when you do not always have access to the system while developing your application.

You will need the right team.

Make sure you have experienced players in your team that understands the concept of event-driven architecture. It’s a new field that may replace the traditional architectures of many current companies. You will need to guide your team correctly to a system that might be completely new.

So, is Event-Driven Architecture for you?

Event-Driven Architectures can open the doors for integration within your system. You want to be able to scale your solution efficiently and also expand functionalities with ease. EDA improves your agility and provides excellent support to acquire and process real-time data. According to Gartner, Over 75% of new business ecosystems will need support for event processing.

Consider using EDA if you meet the following needs:

• You need to process the same event with more than one service
• You prefer a horizontally scaled system
• You want to implement a microservices architecture

So, are you part of the 25% or 75%? Let us know!