How Event-Driven Architecture saves lives – literally and figuratively
Event-Driven Architecture (EDA) is used in many modern applications and microservice-based approaches. More applications use this type of architecture as it provides extra opportunities for integration and scalability. Especially, when you integrate your software system to 3rd party systems, Event-Driven Architecture can be a game-changer. EDA is an integration pattern that responds to an event created in a system. It allows 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, which requires 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 transmits to one or more event consumers through an event transporter or broker (event bus). The event consumer may have a 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 might decide to buy another third-party device, which 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. Event-Driven Architecture smoothly integrates with other services across simple and complex platforms.
Car Fuel Level Sensors
Your car’s sensor 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 that the tank needs to get a refill. Imagine you would have to gauge your tank level every single time… 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. It 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 complex Event-Driven Architecture systems. They use many 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 can’t handle the amount of incoming data they collect. Especially in real-time or at massive scale. It becomes increasingly difficult for companies to manage the data they generate.
And so…
Event-Driven Architecture is the perfect fit to this. It enables systems to accept a tremendous amount of incoming data or events which 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 loosely coupled to 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 loose coupling 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 easier
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,