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.

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 describe the exact state of the world at time X.

Similarly, a domain expert will probably talk about a series of events when describing a process. When you use event sourcing, it becomes easier to model this in your system.

Generating reports becomes easy

Want to know how many times a user changed their email address? With event sourcing, you already store all this data.

Want to know how many times an item is removed from a user's cart? Simply count the EventRemovedFromCart events.

With event sourcing, you have way more insights into your data, and you can generate reports retroactively.

You have a reliable audit log

You can generate an audit log that shows exactly how a system got into a state.

Think of your bank account, for example. Event sourcing generates a log of transaction events that makes it crystal clear why I’m broke at the end of every month.

Why Not Use Event Sourcing

Sounds great, but what’s the catch?

My personal experience with event sourcing is that it adds extra complexity to your system. More complexity means that it is harder to introduce new developers, takes longer to add new features, and is harder to maintain.

If you’re building a relatively small-scale system that does not need a secure audit log, implementing this is probably more hassle than it’s worth.

If you want to learn more about event sourcing, I recommend this presentation by Greg Young.