↓Skip to main content

Event sourcing

·4 mins
Programming
Table of Contents

For many software applications, we generally only think of what their current state is and how operations might need to update that state.

But in some cases, it’s useful to consider how the application arrived at that state. That’s where event sourcing comes in.

Santa delivering presents #

Santa delivers presents everywhere on the night before Christmas. To achieve this, he travels from house to house all the way across the world.

Let’s say we want to keep up with Santa’s journey.

Ordinarily, we might architect this like so:

flowchart LR LocationTracker["Location Tracker"] LocationData[("Location Data --- latitude: string longitude: string")] visitLocation["visitLocation()"] getCurrentLocation["getCurrentLocation()"] LocationTracker --> visitLocation LocationTracker --> getCurrentLocation visitLocation --> |writes to| LocationData getCurrentLocation --> |reads from| LocationData

It’s simple enough: as Santa visits each house, we will update the current location and store it in the database. Then, we can just query the current location for our Santa tracker application to show where Santa is.

As Santa takes the following route:

  1. San Francisco
  2. Tokyo
  3. London
  4. Hong Kong

Santa’s location after each step is:

Stop LocationData
1 lat(SF), long(SF)
2 lat(Tokyo), long(Tokyo)
3 lat(London), long(London)
4 lat(HK), long(HK)

At the end, we know that Santa is in Hong Kong.

But wait.. it’s great that we can find Santa’s current location, but we know nothing about his route! Did he get to Hong Kong from Tokyo? From San Francisco? We don’t have enough information with this approach, but we can fix that with event sourcing.

What is event sourcing? #

Event sourcing1 is essentially modeling the state of a system as a series of events. These events are immutable and stored in a database.

Each event updates the state of the system. The current state of the system is the end result of applying all the events. A neat effect of this is that it’s possible to know the state of the system when a past event occurred.

Santa tracker v2 #

Let’s try setting up our Santa tracker with event sourcing.

flowchart LR LocationTracker["Location Tracker"] EventStore[("Location Events Store [Event 1] ts: timestamp latitude: string longitude: string - [Event 2] ts: timestamp latitude: string longitude: string ... [Event N] ts: timestamp latitude: string longitude: string")] visitLocation["visitLocation()"] getCurrentLocation["getCurrentLocation()"] LocationTracker --> visitLocation LocationTracker --> getCurrentLocation visitLocation --> |appends new event| EventStore getCurrentLocation --> |replays events| EventStore

When Santa takes the same route as in our original example, the events will look like this:

Stop EventStore
1 ts0, lat(SF), long(SF)
2 ts0, lat(SF), long(SF) —> ts1, lat(Tokyo), long(Tokyo)
3 ts0, lat(SF), long(SF) —> ts1, lat(Tokyo), long(Tokyo) —> ts2, lat(London), long(London)
4 ts0, lat(SF), long(SF) —> ts1, lat(Tokyo), long(Tokyo) —> ts2, lat(London), long(London) —> ts3, lat(HK), long(HK)

Now we can tell that Santa got to Hong Kong from London. And then that he came to London from Tokyo. We can chart Santa’s entire route this way!

Real-world use cases #

Event sourcing can be used in a few real-world systems.

For instance, with financial transactions or with transport and logistics.

In financial transactions, it’s helpful to keep track of each addition or removal in an account to meet compliance requirements and with fraud detection.

Then in the logistics realm, event sourcing can help keep track of supply chains and can be used to monitor routes or disruptions.

Drawbacks #

Like many patterns, event sourcing shouldn’t be used without good reason.

The flip side of tracking all events is that to compute the current state, the system has to replay all the events. There are some optimizations like taking snapshots of the state so that the system only needs to replay events from that point. However, in any case, it’s extra complexity that the system designer has to consider.

For most applications, the simple approach of tracking the current state is good enough.

Also, for applications that need to keep track of history, it’s possible to do so without strictly using event sourcing. For example, in an application where it’s important to track changes that users make, the system can just read the latest state and also keep an audit log by appending user interactions to a database.

  1. Greg Young’s writing on CQRS discusses event sourcing a bit ↩︎