event sourcing

Image of Author
June 6, 2023 (last updated June 6, 2023)

Martin Fowler gives a great introduction to [the idea of event sourcing when he writes]:

The fundamental idea of Event Sourcing is that of ensuring every change to the state of an application is captured in an event object, and that these event objects are themselves stored in the sequence they were applied for the same lifetime as the application state itself.

You can think of it as storing events instead of storing state.

For example, say you have a user blob. You could store the state in a typical manner, in a typical database.

{
  "id": 1,
  "name": "Bob",
  "age": "50",
}

That data had to get there somehow. It was through user (or admin) edits. Those edits can be captured as events. (The following is contrived and likely algorithmically problematic, but hopefully it quickly captures the idea.)

[
  { type: 'new', id: 1 },
  { type: 'modify', id: 1, data: { 'age': '50' } },
  { type: 'modify', id: 1, data: { "name": "Bob" } }
]

You can calculate the same state from both.

Databases are often referred to as "the source of truth", aka, "the source". This is helpful heuristic to remember was event sourcing is all about: storing events instead of state as your "source".

Tradeoffs

One potential upside of event sourcing is that you get an event log "for free". Your event log is you data source. You can see, for example, in the event sourced data above, that age was added before name. Maybe that caused a bug in your system. You would not have found that in a "state sourcing" system without something like an event log.

One potential downside of an event sourced system is state management is more complicated now. Recomputing state is infeasible at scale, and as a result, systems will maintain snapshots of state. For example, everyday, you can compute a snapshot and then use that as the base state for the next day.

The what and when tension

There is a symmetry here. One the one hand, a state source with a secondary event system, and on the other hand, an event source with a secondary state system. I'm currently thinking of it as a when/what distinction. An event captures 'when' trivially, and 'what' non-trivially. State captures 'what' trivially, and 'when' non-trivially.

In a high-minded sense, the what-and-when tension can be seen as space-and-time tension. And, maybe, tension is a poor choice of word, because really space and time are "just" the four fundamental dimensions of physics. There is no tension, there is just expressing the "truth of things" in a time-way or in a space-way.