In the last 25 years, much has changed regarding the way that we design and develop software. Back then, we were using static HTML files stored on a remote server, and the client’s only job was to make a connection to that server and retrieve them. Nowadays, the software is waaaay more complex with patterns designed to push the limits of existing hardware, improve the speed of development, and also provide an amazing user experience.

In an Event-Driven Architecture ( EDA for short ) the event is the core of the entire system. We don’t really care about the data! What we care about instead are the events flowing through the system which are relevant for the business. 

This was an interesting lesson that we’ve learned across many years. In fact, the current state of EDA is a sum of learnings discovered while trying out different things.


Event-Driven Architecture Evolution

Service-oriented Architecture ( SOA )

We’ve all been there… All the teams from the company are working on a single application ( monolith ). At some point, a few things start to happen: the development velocity starts decreasing… like super fast, the solution becomes more and more unstable, much time is being lost while building and deploying the app, etc. SOA came as a promise to solve these issues by breaking up the massive monolith into multiple services. This way, the apps are no longer huge, and the development effort could be kept to a minimum. Breaking up the monolith into multiple services solved some issues, but some other problems emerged?! Now, we need to figure out how to make those services to properly communicate with each other. 


Enterprise Service Bus ( EBS )

Using network calls between services, it’s a simple way to solve the communication issue, but it also implies strong coupling. Also, a few other questions popped up like: What if one service talks JSON and the other one accepts only XML? What would happen if one of the services goes down? The answer to these questions, and many others, was addressed by EBS. Enterprise Service Bus was just another layer added to the system, which acts as a middleware between services, facilitating the exchange of data between them. We can already see the event aspect of this form of communication, although we’re not really there yet. We still consider the data as the centerpiece of the system.



We often see the phrase “microservices are SOA done right”. When we compare these 2 terms it is all about size. Microservices are fine-grained services, usually designed to solve problems from a single domain of the business. Whereas in SOA we find much larger services that deal with an entire spectrum of problems.  The data(base) is no longer the centerpiece of our system, but instead, we focus more on the domain and how the business operations are mapped inside that domain. 


Event-Driven Thinking

With an increased focus towards domain modeling, Domain-Driven Design ( DDD ) blossomed and more and more solutions were built using this approach. In DDD we already have the concept of a domain event. A domain event is nothing more than an event that is relevant to the business. A user adding a product to the cart is a relevant event to the business, but him/her eating pizza for lunch might not be that relevant. Having these concepts well established ( Microservices and Domain-Driven Design ) we can now start designing architectures that are focused on the events flowing through the system and not really caring about the data.


EDA Implementations

Event Streaming

It’s not really about viewing video content on one of your favorite streaming platforms! Streaming is a pattern, and it’s all about seeing data as an endless flow of records passing through the system. Viewing video content online is called streaming because under the hood it’s actually using this pattern. Try to think of a LIVE feed! Do we know when it is going to end? NO! Are we receiving the entire content at once? NO! While watching such content we receive it bit-by-bit, maybe a second at a time. While receiving a second of that video content, a media player starts rendering it. This process takes over and over until the LIVE feed is finished. The exact same mindset can be used for event-driven architecture, just that instead of video content we have streaming events.  One of the best examples that I can give is banking alerts. The moment we pay in a shop, we also receive an SMS ( or email ) letting us know that our card has been used. Another interesting implementation is IoT devices. They are continuously producing events triggered by sensors ( temperature, humidity, light, etc. )  and underlying systems can process those events, e.g: the heating system starts when the temperature has fallen under a specific point. 


Reactive Systems

The code that we ( as developers ) are writing may be perfect, but everything else is NOT! The network is not perfect, the storage is not perfect so we often get calls at 3 a.m. because one of our services is down. Reactive systems are a solution to all these imperfect aspects by tackling 4 core principles declared in the Reactive Manifesto:

  • “Responsive: The system responds in a timely manner if at all possible.”
  • “Resilient: The system stays responsive in the face of failure. “
  • “Elastic: The system stays responsive under varying workloads.”
  • “Message Driven: Reactive Systems rely on asynchronous message-passing to establish a boundary between components that ensures loose coupling, isolation and location transparency. “


Serverless and FaaS

Function as a Service ( FaaS ) is an implementation of the serverless model that uses the event-driven mindset. Functions are, by definition, small operations performed in a relatively short duration ( most of the cloud providers limit the execution time to a couple of minutes ). How do we know when to run these functions? You’ve guessed it right… Every function will run when a trigger is activated, or we can also say “when an event occurs”. Recently, we’ve seen also serverless frameworks like KNative or Apache Openwhisk gaining popularity. These frameworks can be used on top of Container Management Services like Kubernetes and run serverless loads triggered by different kinds of events. The idea remains the same, just that in the case of serverless frameworks we are not really using cloud services but we are setting up ourselves the underlying infrastructure.


Event-Driven Architecture Timeline


Today, the Event-Driven Architecture landscape is way bigger than it was 10 years ago with varied possibilities in terms of designing solutions and solving challenges.