Event Driven Architecture
The event driven architecture pattern is there for a while now, everyone is implementing events in one way or another. Some of them are successful implementations while others turn out to be an unnecessary complication. Like every other architecture pattern Event Driven also has its own application and therefore should be considered carefully. This section is for the most common ones.
What is Event Driven Architecture?
Event driven architecture is the one in which the flow of a program execution is determined by events.
Some will argue that above definition tends to simplify a complex pattern in one statement and I would agree with them because as they say “Devil is in the details”. Throughout my career I have worked on several forms of event based architecture patterns. Below are some of the common ones -
1. Event Notification
This is the simplest one and I am sure this pattern must have been used by many of us somewhere in our career. In this pattern a system notifies the other system with an event about a change in its domain. The sender often doesn’t require the response from the receiver. This pattern in itself is as old as the hills, remember the good old email notification module which subscribed to a queue to listen to notification events.
This is a nice pattern as it lets you decouple your business logic and is pretty straightforward to implement. However as it implies that excess of anything is bad therefore if you tend to exploit this pattern you will end up with your business logic distributed all over the place. After a while it will be difficult to understand what is happening in an execution flow unless you monitor the flow in the live system.
2. Event Carried State Transfer
The event in the “Event Notification” pattern described above doesn’t carry much information therefore the receiver often have to query the sender for more information. This often becomes a bottleneck if there are a lot of calls going to the sender from various receivers.
The events in this pattern carry the entire state so that receiver doesn’t have to contact the sender for more information. This pattern is essentially remediate the bottleneck of “Event Notification” pattern described previously.
The obvious downside of this approach is data duplication which may be fine in some use cases while a matter of concern for others. The main advantage is resilience and reduced latency as the downstream systems do not depend on upstream systems to retrieve information.
3. Command Query Responsibility Segregation (CQRS)
CQRS is pattern which as its name implies segregates the read and write operations of a data store. This pattern usually works in conjunction with all the patterns defined in this article. It is also possible to implement this pattern without events, however people often link this pattern with events therefore I will cover this pattern as well.
The justification for this pattern is that the tradition approach in which read and write operations execute in parallel, tends to be more contentious, specially in high load use cases. Often read and write models different therefore this pattern dictates to segregates the two; such that both can be independent of each other. This provides better scalability and resilience at the cost of complexity.
4. Event Sourcing
This is the most complex pattern of the four. This implies the use of events to store data in an append only data store. The core idea is that whenever there is a change in state, we record the change in state instead of updating the state itself. So we end up with a record of events that contain the details of what was changed in the state at that point in time. The state in itself can be constructed by processing the events at any point in the future.
This pattern is useful for strong audit and data reporting purposes as you have all the changes recorded in the event store. This pattern is also good for fail safety as whenever a downstream system fails its state can be reconstituted from the events. Event sourcing also optimizes the write performance as a record is appended for each change of state.
BUT (there is always a but) it has certain issues as well. The complexity is one of the main issues here. The data store size increases exponentially compared to traditional approaches as there is a new record stored for each change. This can be remediated by using snapshots which essentially means that state is reconstituted by replaying the events from last snapshot. However the replaying of event also becomes a problem when there is integration with other systems. Therefore this pattern should be evaluated carefully before considering for implementation.
Conclusion
As described above Event Driven architectures solve many problems of modern systems and some of them are here from quite a while. However each pattern should be carefully evaluated against the business case before moving ahead for implementation.
