Many Meanings of Event-Driven Architecture

"Event-driven architecture" gets used to describe several distinct patterns: event notification, event carried state transfer, event state transfer, and event sourcing. Each has its own tradeoffs. Fowler also covers using a memory image instead of persistent storage, and the Command Query Responsibility Segregation (CQRS) model for separating reads from writes.

Triggering Call and Response

Fowler starts by pointing out that EDA is not one specific thing but a broad label covering several patterns. The first is event-triggered call and response. In his example, an insurance company re-runs its quoting process whenever a customer updates their address. Because the quoting system listens for the address-change event rather than being called directly, the two systems stay decoupled.

Event Notification

Instead of explicit dependencies between systems, teams can listen for specific events from a centralized event repository and respond accordingly. This lets different teams share and reuse events without tight coupling between their systems.

Events vs. Commands

Events and commands play different roles in these systems. Events inform other parts of the system without caring about the outcome, while commands tell a specific system to do something. Both are message-based, but the distinction matters for how you design the boundaries between components.

Event Carried State Transfer

In this pattern, events carry state information along with them, reducing the need for systems to call back to the source for data. This cuts down on inter-service traffic, but introduces eventual consistency problems since each consumer holds its own copy of the data.

Event State Transfer and Event Sourcing

Event state transfer is a less common pattern where data is duplicated to avoid callbacks. Event sourcing takes a different approach: every change is captured as an event object and appended to a log. Because the full history is preserved, you can rebuild application state at any point. Fowler compares this to version control systems like Git, where you can reconstruct any past state from the commit history.

Snapshot Effect and Memory Image

Event sourcing also enables a snapshot approach that simplifies tracking changes over time. Some systems take this further by keeping application state entirely in memory rather than persisting it to a database. LMAX, a retail trading platform, uses this approach to achieve the low latency its workload demands.

Challenges and CQRS

The complexities of event-driven systems include versioning issues, the need to store both input and internal events, and the role of CQRS (separating read and write components so each can use a model suited to its access patterns).

Source