2 // Why Event Sourcing?

Databases have been and still are the most common way to store and retrieve data. However, Freym is based on event sourcing. This chapter explains the main differences between databases and event sourcing.

Event Sourcing is a design pattern that meticulously records all data changes as events. Using event sourcing, you can reconstruct the entire sequence of events that led to the current state of the data.

Relational Database - Example Workflow

To illustrate the difference between databases and event sourcing, consider this simple example. Let's say our user Thomas is shopping at The Beatles Fanshop. In the database world, his shopping cart is stored in a table that looks like this:

Note that the table only shows the current state of Thomas' shopping cart. If Thomas adds another T-shirt to his cart, the table will be updated to reflect the new state.

Event Sourcing - Example Workflow

Let's try to implement the same workflow in a system based on event sourcing. We will follow the Event Sourcing pattern and store all changes to Thomas' shopping cart as events.

This is the Event Stream for Thomas' shopping cart:

All of the information in Thomas' shopping cart is persisted, including changes that would be invisible in a relational database. This detailed history of the data allows you to jump back in time to any point in the past and serves as a detailed audit log.

Wrap-Up

The main difference between databases and event sourcing is the way data is stored.

In the database world, only the current state of the data is stored. In the Event Sourcing world, all changes to the data are stored. This allows for a detailed history of the data and the ability to go back in time.

Further Reading Beyond The Freym Journey

Want to learn more about event sourcing or messaging now? Select one of the following articles to dive deeper into the topic.