What’s the most important part of Event-Driven Architecture?

Events are the most important part of Event Driven Architecture(EDA).

In application that has the implementation EDA, different components communicate by sending and receiving events.

But what exactly is an event?

In simple terms this is something that has occurred.

However, in detail it is a significant occurrence or happening within a system or a domain that is of interest to the participants in the system. Moreover, events can represent a wide range of activities, changes, or notifications that have an impact on the state of the system. These events are often used to trigger or communicate between different components or services in a decoupled and asynchronous manner.

Examples:

• A customer signing up for your application
• A payment is received for an order
• A failed authentication attempt
• A transaction completed
• Account balance updated
• A user logged in
• A post published

There are mainly three different patterns I have come across while dealing with events.

1. - Event Notifications
2. - Event-Based State Transfer
3. - Event Sourcing

[1] Event Notifications

In this case, the event just notifies that something has occurred.

The event carries the absolute minimum state. For example, just the ID of an entity like a new order. Minimal data is sent over the network.

In some cases, the receiving components may record the information for auditing purposes. But others may call the source component to fetch additional information about the event.

Notification-type events are general-purpose in nature and suitable for broadcasting requirements.

[2] Event-Based State Transfer

This is more like the asynchronous relative of REST.

Instead of REST’s on-demand pull model, event-based state transfer follows a push approach.

Data (id + information) is sent out to be consumed by any components. Some components may create their own local cached copies of the data while others may take some other action based on the data received.

The advantage is that the consumer need not call back the source component for additional information.

The entire information is right there in the event payload.

[3] Event Sourcing

This is pattern not about event transmission but event storage.

The state of an application is determined by a sequence of events rather than by the current state of the data. In other words, instead of storing the current state of an entity, you store a series of events that represent state transitions. These events are then used to reconstruct the current state whenever needed.

According to Martin Fowler,

The fundamental idea of Event Sourcing is that of ensuring every change to the state of an application is captured in an event object, and that these event objects are themselves stored in the sequence they were applied for the same lifetime as the application state itself.

Changes to an entity are not captured as irreversible modifications but are stored as events in an event store.

These changes can be read and processed to recreate the final state of an entity whenever required.

In conclusion, event driven architecture (EDA) offers diverse communication patterns like event notifications, state transfer, and event sourcing. As of this, each serve distinct needs in data transmission and storage. More-significantly, selecting the right pattern depends on system complexity and scalability.