Skip to main content

Event Driven Architecture

Event Driven Architecture is a design pattern that uses events to communicate the state of the domain. Events are messages that are published by a component when a specific action within that domain occurs. Other components can subscribe to these events and react to them accordingly. This allows for the decoupling of components a system, as they do not need to know about each other in order to communicate.

Each event is a self-contained message that contains all the information needed to describe the action that occurred. This allows for the event to be processed independently of the system that generated it. Events can be used to trigger actions, update state, or notify other components of changes.

The Event Stream​

An Event Stream is a log of all the events that have occurred within the system. The Event Stream has several key characteristics the make it a powerful tool for building distributed systems:

Ordering​

The order of events matters. Say you have two events for an aggregate Item: ItemCreated and ItemUpdated. If you receive an ItemUpdated event before an ItemCreated event, you will not be able to process the ItemUpdated event correctly, as it may not have the necessary context to do so. Therefore, it is critically important to maintain the order of events.

Event Streams order events into topics, which are separated by a key into partitions. For any given key, the order of events is guaranteed to be maintained. This allows for the system to scale horizontally, as events can be processed in parallel across multiple partitions.

Immutability​

Events are immutable. Once an event is published, it cannot be changed. This ensures that the event stream is a reliable source of truth for the system. If an event needs to be updated, a new event should be published that corrects the error.

This is important for ensuring that the system is reliable and consistent. If events could be changed after they were published, it would be difficult to trust the data in the event stream.

Migrations can be handled by publishing new events that correct the data in the event stream. This allows for the system to evolve over time without breaking the guarantees of the event stream.

Replayability​

Events are chronologically sequentially ordered in an event stream. The event stream is a log of all the events that have occurred within the system. This allows for the system to be rebuilt from scratch by replaying the events in the stream. This is useful for debugging, auditing, and scaling the system.

Furthermore, the event stream can be used to build projections of the domain into another service. Projections are views of the domain that are built by processing the events in the stream. This allows for the system to be queried in real-time without having to query the entire event stream.

Data Completeness and Consistency​

As an Event Stream is a log of all the events that have occurred within the system, it is important to ensure that the data in the stream is complete and consistent. Critically, this means that ALL state changes MUST be published as events. If a state change is not published as an event, it will not be reflected in the event stream, and the system will not be able to recover from that state change. In addition, "manual" state changes (such as manually changing a value in the database) should never be performed, as they can lead to inconsistencies in the event stream.