Demystifying the Event Driven Architecture - An introduction (part 1)

(Photo royalty free: Pikrepo.com)

High throughput, resiliency, scalability and speed—are you searching for a way to leverage microservice integration to handle all the event-driven communications in your growing architecture landscape?

Search no further.

This series of articles guides you through the world of integration using microservice architecture and specifically explores the world of Event Driven Architecture (EDA). It’s a central story to organizations moving forward into the digital world and is worth exploring as part of your strategy for continued success.

We’ll discuss if EDA might be the best choice for your microservice integration solutions, and more importantly, when you might not need EDA at all. There will be a tour of use cases that lend themselves to EDA solutions and present a few real world examples for your consideration. Lastly, we’ll look at the open technologies that can help you to implement an EDA architecture.

The basics

Before we examine the question of whether to use EDA or not, let’s examine what we are talking about first. EDA is an approach to develop applications in order to maximize the benefits of microservices. Simply put, EDA is a software development method for building applications that asynchronously communicate or integrate with other applications and systems via events.

Events are used as a way of establishing communication between applications, as well as with systems. This is called integration. An event can be any occurrence or change in state that is identified by the application. A good example of an event is the addition of a product to a shopping cart on an ecommerce site. An application designated as a Producer detects the event and sends out relevant data in the form of a message. The middleman, an Event Processor, directs the message to an application designated as a Consumer, which receives the message. Multiple consumers can receive the same message and utilize or even process the associated data in their own way, to accomplish the specific job for which the application is designed.

EDA's asynchronous event-based communication differs from synchronous communication in which two applications make a direct connection, most commonly via application programming interfaces (APIs). Conversely, asynchronous communication is event-driven, allowing multiple applications to communicate simultaneously and rapidly, in real time. EDA is considered the best way to enable asynchronous event-driven application interaction.

Today's development model relies on revolutionary technologies—like microservices and cloud-native development—that make distributed systems and applications possible. Distributed means the system or application is built from components physically located in different places. The secret to making distributed computing work is good solid communication between these components

Traditional synchronous architecture cannot handle the performance and scale needs of  distributed systems, and consequently applications based on this more conventional architecture face debilitating challenges in a distributed environment, including communication latency, system degradation, unpredictable failures, and more. Moving to EDA helps developers overcome these challenges. EDA requires minimal coupling between the services, while they can still communicate with each other, which makes EDA optimal for modern, distributed applications.

To EDA or not

In the next article, we’ll explore a list of cases that lend themselves explicitly to implementing an EDA solution. Now we’re going to look at a few reasons where it might make sense to pass on EDA solutions.

One of the first things you learn and read a lot about is how EDA means loose coupling between everything in your architecture. Microservices don’t need to know about each other, systems don’t need to know about each other, and applications don’t need to know about each other. While this is often a strong guiding force when implementing EDA, some projects lend themselves to being designed as tightly coupled. If your application landscape is such that you desire to process data at higher volumes and need to have a single point of truth (for example, a database) for that data, then EDA would not be for you.

If your applications and interactions with your users does not require real-time or near real-time responses, then events and EDA are not a necessity for your solution. Real-time solutions are highly dependent on processing events, often at high volume, with as much speed as possible. Not all applications are in need of real-time responses.

There is a vast amount of complexity in EDA architectures, which becomes a double edged sword. This means trading off the ability to react to large event volumes at near real-time speed with complexity as you strive to understand or trace problems as they happen in that architecture. If your current resource team is not up to the task of asynchronous debugging problems, it might not be the best solution path to take with regards to EDA.

This is not a complete listing of all reasons to not use EDA, but gives you an impression of the various possible reasons to use an EDA, or not.

What’s next?

Now that you have an introduction to the world of EDA, we’ll continue in the next article by exploring the use cases that do lend themselves to an EDA solution.

If you’re interested in exploring EDA solutions using open source technologies, then take a look at
getting started with event-driven architecture using Apache Kafka or this free e-book on designing event-driven applications