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.
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.
Event notification is excellent because it implies a low coupling level and is pretty simple to set up.
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.
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.
- 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.
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.
- 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.
- 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.
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.
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.
- 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.