Event Driven Architecture
Event Driven Architecture Link to heading
The event-driven architecture pattern is a popular distributed asynchronous architecture pattern used to produce highly scalable applications. It is also highly adaptable and can be used for small applications and as well as large, complex ones. The event-driven architecture is made up of highly decoupled, single-purpose event processing components that asynchronously receive and process events.
It is suitable for applications or systems that transmit events among loosely coupled software components and services. An event-driven system consist of typically consists of event emitters (or agents), event consumers (or sinks), and event channels. Emitters have the responsibility to detect, gather, and transfer events. They do not know anything about consumers, it’s existence or how it processed the events. Sinks have the responsibility of applying reaction as soon as an event is produced. The sink can process the event or do some transformation and forward the event to another component. Event channels are conduits in which events are transmitted from event emitters to event consumers.
In Event-driven systems events are processed in different systems, it is very difficult to maintain atomicity. Things which are needs to be done together as an atomic transaction should be part of one system. EDA is horizontally scalable and resilient to failure as components are loosely coupled and can be scaled independently.
There are four most used patterns in event driven architecture which Martin flower has described in his blog here.
Event Notification Link to heading
In this pattern, a system sends event messages to notify other systems of a change in its domain. Source system does not care much about the response. Often does not expects a response, or if there is a response it will not be direct. This provides low coupling between different systems.
This pattern is simple and easy to set up, but It can become difficult to debug and modify if event notification flows through various systems. In this pattern, event contains minimal information and sometimes they may need to contact the sender for more information while processing the event.
Event Carried State Transfer Link to heading
In this pattern, an event contains all details required by a system to process the event and each system maintains its own copy of the data. The system can reduce latency by not making the remote call for information and can update its own copy of the data. In this pattern, there will be different copies of the same data which can lead to inconsistency of data across the system at some point of time.
Event Sourcing Link to heading
In Event Sourcing EDA, we store every change in state as an event in the event store, so that we can rebuild the system state by reprocessing the event at any time in the future. The event store becomes the principal source of truth. The best example of this is a version control system.
Event sourced system provides a strong audit capability to the system but sometimes it can become difficult to rebuild the state if it depends on some external system.
CQRS (Command Query Responsibility Segregation) Link to heading
Command Query Responsibility Segregation patterns use different data structures for reading and writing information. CQRS can be used in systems where there are no events but it is most commonly used in combination with above patterns.
References