When to Use Event Sourcing

Event sourcing can be awesome, but it does add complexity to your system

What Is Event Sourcing?

Most web applications store the state of a system in the database.

Suppose you’re asked to design the database of a webshop. Most likely, a traditional sequel database design will have a users, products, and orders table — representing the state of the system.

Let’s assume you start coding away and eventually launch the webshop. After a few weeks, the product owner would like to know how many times users update their email address, on average.

In this traditional database design, when a user updates their email address, a query looking something like this is executed:

UPDATE users SET email='newemail@mail.com' WHERE id=1

The problem is that there is no event log storing this change in a traditional sequel database.

You could build an extra column event_log and add a “user changed email” every time a user updates their email address. However, there are a few issues with that:

• It requires extra work to build the feature.
• It makes the database design more complex.
• You will only generate these events from the moment you implement this feature, there is no way to generate these events retroactively.

This is a perfect example of where event sourcing is awesome!

With an event sourcing design, you don’t store the state of the system. Instead, you store the events.

For example, when a user signs up, a UserCreated event is stored. Then, when a user updates their email address, a UserChangedEmail event is stored.

Example events in an Event Sourcing system

Why Use Event Sourcing

Represents how we think

In the real world, people think in events. When somebody asks you how your day was, you will most likely tell them the interesting events that occurred. And you probably won’t…