Beginners Guide to Event-Driven Architecture

The Myth?

Legend has it that you can only interact with web services using REST APIs. The same legend also states that HTTP is the only way of communication on the interweb. And I am here to bust this myth by introducing you to Event-Driven Architecture(EDA)

The Evolution

Since its conception in the 1970s, EDA has been waiting patiently for its moment. EDA is taking center stage to solve modern business challenges and deliver real-time user experiences with the rise in event-driven APIs. While EDA might not be the answer for every business challenge, when applied to the proper use cases it can transform a company’s operations and customer service. It’s becoming increasingly clear that for an enterprise to stay competitive in the modern marketplace, it needs to know where and how to use EDA.

What Is An Event?

An event is an action that occurs as a result of the user interactions, such as a mouse click. An example of an event is a user clicking a button on an app which then triggers an event known as "click".

The image below visualizes what an event does when you try to pay for something on the internet.

What is an Event-Driven Architecture(EDA)?

Event-driven architecture is a software architecture and a model for application design, in which decoupled applications can asynchronously publish and subscribe to events via for example an event broker (modern messaging-oriented-middleware).

I know you're currently wondering 🤔 what just happened, I'll break down what it is in a moment. Just hang in there.

So, what Event-Driven Architecture basically does is enables your application to act based on events as they occur. This simply ensures that when an event occurs, information about that event is sent to all of the systems/people that need it.

This is a very simple concept, but these events have quite a journey to travel because they need to efficiently move through a multitude of applications written in many different languages, using different APIs, leveraging different protocols, and arriving at many endpoints such as applications, analytics engines, and user interfaces.

Why EDA Instead Of HTTP Requests?

When I started learning about EDA I kept wondering why to use it when I can just simply use HTTP requests and after a couple of research I came to realize that in a typical request-response scenario, the client has to wait for the server to respond; and by doing that, it blocks all its activities until it receives a response from the server or the timeout expires.

Now, If we take this behavior and put it in a microservices architecture using chained calls across the system, we can easily end up with what is called a “Microservices Hell.” Everything starts with one service call, let’s call it service A. But then, service A needs to call service B, and the fun goes on. The problem with this behavior is that if a service has resources blocked (e.g: a thread is hanging), timeouts are now exponential. If we allow a 500 ms timeout per service and there are five service calls in the chain, then the first service would need to have a 2500 ms (2.5 seconds) timeout, whereas the last service would need to have a 500 ms timeout.

Why The Sudden Shift?

In contrast, the sudden shift to event-driven architecture is primarily driven by speed and responsiveness. This isn’t as simple as internet users wanting data on request; it’s an entirely different paradigm where, increasingly, people are looking for a proactive, real-time and individually customized experience. In other words, don’t wait for me to ask for something, inform me when something of my interest changes.

In my opinion, I don't feel the shift towards EDA is driven solely by speed. Literally, anyone that has seen API growth sky-rockets e.g In a scenario where the API has taken far more users than expected, would see how scaling becomes an issue.

Another use-case why people are shifting to EDA is because they want to know what is happening in real-time without them asking unlike in the case of REST API.

What Next?

Curious to know what the next step is in our journey in Event-Driven Architecture? Well, in the next chapter we'll be looking into how EDA works in which we'll be discussing the major components that make up an event-driven architecture.

Stay tuned 🤞