- Published on
Many Meanings of Event-Driven Architecture
- Authors
- Name
- Skim
There are different patterns that fall under the term event-driven architecture (EDA), including event notification, event carried state transfer, event state transfer, and event sourcing. Depending on the system's needs, there can be benefits and challenges of each pattern. Fowler also discusses the concept of using a memory image instead of persistent storage to store application state, and explains the Command Query Responsibility Segregation (CQRS) model for updating and reading from the permanent store.
Triggering Call and Response
Fowler begins by explaining that EDA is not a rigid, predefined framework but a broad concept that embraces several patterns. The first pattern discussed is event-triggered call and response. An example of an insurance company's system that triggers the insurance quoting process when a customer changes their address showcases how event-driven architecture can eliminate dependencies and coupling between components.
Event Notification
Instead of explicit dependencies between systems, teams can listen for specific events from a centralized event repository and respond accordingly. This approach fosters flexibility and modularity across systems, allowing events to be shared and reused among different teams.
Events vs. Commands
It is important to distinguish the difference between events and commands in event-driven systems. Events inform other parts of the system without necessarily caring about the outcome, while commands trigger specific actions to be taken. Despite the differences, both are message-based patterns that facilitate communication between systems.
Event Carried State Transfer
The event carried state transfer pattern involves using events that carry state information, reducing the need for direct communication between systems. Although it improves performance and reduces load, it comes with eventual consistency issues due to data replication.
Event State Transfer and Event Sourcing
Event state transfer is a less common pattern, where data duplication is used to avoid calling back. Event sourcing, on the other hand, involves capturing change details in event objects stored in a log, enabling the application state to be confidently rebuilt at any time. The analogy with version control systems like Git emphasizes its significance.
Snapshot Effect and Memory Image
Event sourcing can be likened to a snapshot effect that simplifies tracking changes in the system. The use of a memory image instead of a persistent form enhances speed and performance, as exemplified by the retail trading system, LMAX.
Challenges and CQRS
The complexities of event-driven systems includes versioning issues, the need to store both input and internal events, and the importance of CQRS (separating read and write components, enabling distinct models for updates and reads).