Event Driven Architecture Demystified (For Pros)

by | 29.08.2021 | Engineering

Event-Driven Architecture or EDA is talked about with pride inside any organization. But, through last few months, I have noticed a trend that the definition of EDA is not consistent across people and organizations. It’s vague.

EDA is something where you have events at the core and this simplicity has created quite a disconnect about what Event-Driven Architecture is.’ Experience this by asking two connections to talk a sentence about EDA. You would see a distinct disconnect, and as you may understand, this disconnect is not a good sign.

Who likes to get cocaine instead of coke (Coca-Cola) at a store? In the same way, not standardizing things is quite harmful.

But fortunately, things in our Industry are not as severe as consuming cocaine instead of coke. To boil down, we have four principles that govern the definition of EDA in every organization. Some consider EDA a collection of all four patterns, and some think of it as any one pattern or maybe some other enumeration.

What is an Event?

An event is a substantial change in state that occurs when a user performs any specific action. For example, think of an item in a store changing from ‘For Sale’ to ‘Sold’ as you buy it.

Pattern 1: Event Notification Mechanism

In Event Driven Architecture, the pattern which we can implement quickly is the event notification pattern. Event notification is the same thing as that you are imagining. It gives out a notification from the service when any changes or new happenings happen in the event. We can find lightweight events in this pattern. It contains only the basic data. If services that are interested in these events need additional data, they have to request separately.

Simple Amazon S3 Event Notifications (Doesn't resemble Architecture)
Simple Amazon S3 Event Notifications (Doesn’t resemble Architecture)

Let’s say you are ordering from an e-commerce website. You will see while ordering that you get a notification after the completion of the order, and you get one when the order is ready to ship. Also, after confirmation of the order, the website requests shipping because it completes the process and also if shipping requires more information, it will have to request it to the website. The same happens with this pattern, too, which makes the service independent of the shipping service’s API modification and changes.

Advantage

Event notification is excellent because it implies a low coupling level and is pretty simple to set up.

Disadvantage

This pattern is not full proof, and It can cause problems too. It can become problematic if there is a logical flow that runs over various event notifications. A problem may occur because it can be hard to see such a flow as it’s not explicit in any program text. Most of the time, the only way to figure out this flow is from monitoring a live system. It can make it hard to debug and modify such a flow. The danger is that it’s effortless to make nicely decoupled systems with event notification without realizing that we may lose sight of the larger-scale flow.

This pattern can also lead to a trap. But, we have to be careful of it while using it. The trap can come in the act if the event acts as a passive-aggressive command. It simply means that while carrying out an action by the recipient from the source system, it uses a command message styled as an event.

Pattern 2: Event-Carried State Transfer Mechanism

ECST Pattern or Event Carried State Transfer Pattern helps in adding more states to an event. In simple words, it helps add more data to the event so that the content becomes more describable to the service. But, while implementing this pattern, we have to keep in mind that we can’t add too much data because it can confuse other services.

Event-Carried State Transfer Mechanism
Event-Carried State Transfer Source: Medium

While ordering, the event instead of defining only the order ID, if it adds more information like name, quantity and price of the item along with customer ID, it will help the service understand the order more clearly. It is the same thing that ECST does in simple terms.

Advantage

  • We gain greater resilience from this pattern since the recipient systems can function if the customer system becomes unavailable.
  • There is a reduction of latency, as there’s no remote call required to access customer information.
  • Another advantage is that we don’t have to worry about load on the customer system to satisfy queries from all the consumer systems.
  • We also get significant advantages like great decoupling and high availability. Now, the order service can work without customer service as it has all the necessary data regarding the order.

Disadvantage

An obvious disadvantage of this pattern is that it carries around lots of data and lots of copies.

Pattern 3: Event Sourcing Mechanism

Event Sourcing or ES pattern helps in the storing of application state as the sequence of events. Application State is not a single record that we can keep in a database. It is the sum of all the events that happened in the system. This pattern helps in storing the Application State through the replaying of events. We know Event Source as the Single Source of Truth (SSOT).

Let’s assume you are depositing money in a bank account. The account statement will not be a single element, but it will be the sum of all the money that you have deposited in your account, along with all the transactions. If you want to check your account history, you can go back and check your previously deposited amount. You can see the exact amount of balance you had in your account a couple of years ago. This is, in simple terms, what event sourcing helps in doing. We can build an application state at any time by replaying events from beginning to end to ensure that we can validate the application state as same as a bank account balance.

Event Sourced Application
Event Sourced Application (Source: Faun Pub)

Advantage

  • The event log provides a robust audit capability which means that accounting transactions are an event source for account balances.
  • Another advantage is the recreation of historic states by replaying the event log up to a point.
  • We can explore alternative histories through event-sourced patterns by injecting hypothetical events when we will replay those events.
  • Event sourcing makes it highly plausible to have non-durable working copies like Memory Image.

Disadvantage

  • Replaying events in this pattern becomes problematic when results depend on interactions with external systems.
  • Problems occur when dealing with changes in the schema of events over time.
  • Many people find that event processing adds a lot of complexity to an application which can be a disadvantage.

Pattern 4: CQRS Mechanism

Finally, the last pattern we can see here is the CQRS. Command Query Responsibility Segregation, or in short CQRS, is the notion of having separate data structures for reading and writing information. This pattern, in simple terms, states that we can use different models to read than write. Implementation of this pattern helps in fulfilling two different requirements. We create separate services for reading and writing and communicate them via Events.

CQRS
Source: IBM

The command side helps in the handling of update requests. It requires consistency. The requirement for scaling is not very high as it processes a small number of requests for most of the systems.

We can optimize reading by storing data in a non-relational database or a relational database in standard form. The scaling requirement is high for the reading side as it gets updated by listening to the events published by the command side. We need to implement the reading side carefully so that it can be easily scalable.

Advantage

In complex domains, a single model for handling both reads and writes get too complicated. So, CQRS helps in simplifying the complication by separating the models. It becomes beneficial when we have lots of reads and a few writes or vice versa.

Disadvantage

  • The prominent disadvantage of CQRS is the duplication of code as we require seperate model for both reading and writing.
  • Point of failures will be more in CQRS because it uses a lot of databases and it can add more complexity.
  • It is quite costly because handling of databases and other hardware will require a lot of money.

Thanks for Reading

Thank you for reading this detailed article. I hope this article covered the various pillars of EDA, and you can deconstruct your architecture to see what components make up your EDA if necessary. Clarity aids in the development and comprehension of your systems.

Feel free to check our other posts and contact us in case you need help in scaling or building your EDA strategy.

Happy Architecting!

Join the Community

The DevOps Awareness Program

Subscribe to the newsletter

Join 100+ cloud native ethusiasts

#wearep3r

Join the community Slack

Discuss all things Kubernetes, DevOps and Cloud Native

More stories from our blog

Linkerd: Looming on Service Meshes

Linkerd: Looming on Service Meshes

Microservices and service meshes have become a staple of the industry as companies realize the full potential of creating an independent architecture that allows for easier scale up, agile development, resilience and streamlined deployment. Many of these applications...

What’s new in Flux v0.17.0?

What’s new in Flux v0.17.0?

Flux2 came with its new update a while ago, and it is sheer exciting for the users because it brought a lot of new features. It also made a lot of new enhancements and updates. We will take a look at the entire catalogue in this article. So, without further a due,...

What’s new in Portainer v2.7.0 BE?

What’s new in Portainer v2.7.0 BE?

A few days ago, Portainer Business Edition came up with their new update. It is quite a massive update with many new features, bug fixes, enhancements and much more. In this article, we will see all of those in a nutshell. Let's start What is Portainer? Portainer is...

DVC (Git For Data): A Complete Intro

DVC (Git For Data): A Complete Intro

As a data scientist or ML engineer, have you ever faced the inconvenience of experimenting with the model? When we train the model, the model file is generated. Now, if you want to experiment with some different parameters or data, generally people rename the existing...

Recap of the Cloud Native Meetup Saar #3

Recap of the Cloud Native Meetup Saar #3

We are looking back on a very successful third edition of our Cloud Native Meetup Saar #3! Togetherer with our co-host anynines, we enjoyed a fun afternoon filled with great speakers, intriguing topics and thoughtful conversations! We welcomed a total of three...

Portainer Ambassador Series ft. Fabian Peter

Portainer Ambassador Series ft. Fabian Peter

Portainer arranged a fun and informative discussion through a one-hour special named “Ambassador Series” on 1st July 2021. It was pretty amazing to see Savannah Peterson as the host and two other guests. One is our very own CEO of p3r.one, Fabian Peter and the other...

What’s new in Longhorn v1.2.0?

What’s new in Longhorn v1.2.0?

Longhorn came with their new update. It is full of surprises. We will peel off one by one to see all the latest updates, features, bug fixes and much more. This one is a much-awaited update, and we will see all of it in a moment. So, without further a due, let's...

Kubernetes Stateful Friend: What’s more to etcd?

Kubernetes Stateful Friend: What’s more to etcd?

The Kubernetes control plane consists of various components, and one of such components is etcd. Anyone starting to learn k8s come across it and memorizes quickly that it’s a key-value pair for Kubernetes with persistence store. But, what’s more to it? Why do we need...

What’s New in Flux 1.24.0?

What’s New in Flux 1.24.0?

Flux 1.24 is out this month with couple of updates and Important notices. Let’s get around what are the updates in the new release. But, first, let’s do a quick intro on Flux. What is Flux? Flux is a tool that checks to see if the status of a cluster matches the git...

What’s new in Istio v1.11?

What’s new in Istio v1.11?

Istio is an open platform for providing a uniform way to integrate microservices. It also manages traffic flow across microservices, enforce policies and aggregate telemetry data. The control plane of Istio offers an abstraction layer over the underlying cluster...

Interested in what we do? Looking for help? Wanna talk about software strategy?