The Event Driven Design model is a popular distributed a synchronous architecture model used to produce highly scalable applications. It is also highly adaptable and can be used for small applications as well as large, complex applications. Event-driven architecture consists of highly parsed, single-purpose event handling components that take and process events as a synchronous.
Suitable for applications or systems that inger events across loosely connected software components and services. An event-driven system typically consists of event emitters (or agents), event consumers (or recipients), and event channels.
In event-driven systems, events are processed on different systems, it is very difficult to maintain atomicity. Things that need to be done together as an atomic process should be part of a single system. EDA is error-resistant because it is horizontally scalable and components are loosely connected and can scale independently.
There are four most commonly used patterns in event-oriented architecture.
- Event notification
In this model, a system sends event messages to notify other systems of a change in the domain. The source system doesn't care much about the response. Typically, if you do not wait for a response or have a response, it is not direct. This provides a low connection between different systems.
This model is simple and easy to set up, but it can be difficult to debug and modify if event reporting is passed through various systems. In this model, the event contains minimal information, and sometimes they may need to contact the sender for more information when processing the event.
- Event Moved State Transfer
In this model, an event contains all the details that a system needs to handle the event, and each system store its own copy of the data. By not searching remotely for information, the system can reduce latency and update its own copy of the data. In this model, there will be different copies of the same data, which at some point can cause system-wide data inconsistency.
- Event Welding
In Event Sourcing EDA, we store every change in the state as an event in the event store so that we can re-process the event at any time in the future to rebuild the health state. The event store becomes the main source of truth. The best example of this is a version control system.
The event-induced system provides a powerful control capability to the system, but sometimes it can be difficult to recreate the state if it is connected to some external systems.
- CQRS (Command Query Liability Separation)
Command Query Responsibility Parsing models use different data structures to read and write information. CQRS can be used on systems where there is no event, but it is most commonly used in combination with the above models.
I hope it's an explanatory article.