Event-Driven Architecture or Event Sourcing?

Same? Not the same?

A Matter of Scale

It’s all a matter of scale; take a look:

• An event-driven architecture (EDA) is a means of communication between contexts, in the Domain-Driven Design sense;

• Event Sourcing (ES) is a pattern found within a context, characterized by append-only writes.

In both cases, information flows in the form of business events, identified by a type (for example: APPOINTMENT_BOOKED), and usually accompanied by a payload. These events are precious (we call them a “golden source”) because they are sufficient to reconstruct the system’s history.

Let’s look at this in detail.

Event-Driven Architecture: A Reactive Approach

The beauty of this approach lies in its decoupling:

• Each context emits events onto a data bus without worrying about who will be listening (broadcast);

• The bus’s responsibility is to deliver events to all contexts that have subscribed to that event type (typically through a topic), and nothing else. It performs no transformation and carries out no processing. These are referred to as dumb pipes, as opposed to ETL (Extract, Transform, Load);

• The contexts that listen to these events, however, do not know which context originated them.

This is a reactive system: each context performs processing in response to events from the outside world, emitting other signals in return.

This behavior is quite unique: it’s important to understand that each context will accumulate (“sediment”) information so it can be used later, when it is queried via its API.

Why is this interesting? Because the alternative for a context is to retrieve the information when it needs it. Consequently, if the context that holds the information is unavailable, the caller cannot work. In contrast, an EDA promotes the autonomy of contexts.

There is much more that could be said on the subject, but the goal is to see how such an architecture differs from Event Sourcing, so let’s talk about Event Sourcing.

Event Sourcing: An “Append-Only” Approach

As we’ve seen before: ES is an architecture found within a specific context. It addresses a specific need: traceability. Accounting and maritime shipping are classic examples (1).

In accounting, if a €100 debit was made in error, you cannot simply delete the corresponding entry, as the risk of falsifying the accounts would be too great. For this reason, the only option is to create a “reversing” event, that is, a €100 reversal entry. Instead of deleting an event, we add one. We can only add events, which is what the term append-only refers to.

In this architecture, we do not store the system’s current state, but rather the sequence of business events that led to that state. The events are sufficient to reconstruct the current state, which is merely a projection. Of course, it’s clear that this approach breaks down when you have to reconstruct the state from 50,000 events (for example, the balance of your bank account opened in 2004). This leads us to create, in parallel with Event Sourcing, a read model (a snapshot of the system’s state), and to reinvent CQRS in the process (the distinction between a write model, for auditing, and a read model, for performance).

Again, we could go much further by discussing commands, decide and evolve functions, and then detailing the link between ES and CQRS (two independent concepts that work very well together). But that would be too much for a single article 🙂

(1) See Martin Fowler’s article on this topic: https://martinfowler.com/eaaDev/EventSourcing.html.