Event Sourcing as the Canonical Source of Truth

Event Sourcing (ES) is a concept that enables us peruse the history of our system and know its state at any point in time. A few reasons this is important range from investigating a bug only occurring under certain conditions to understanding why something was changed (why was customer X’s address changed). Another distinct advantage of event sourcing is that we could rebuild an entire data store (SQL tables, MongoDB collections, flat files, etc…) by replaying each event against a listener. This would look something like the below code:

It’s quite simple and elegant, but more important is that it becomes the canonical data store; the single source of truth. The alone yields some interesting possibilities. One of which I’m quite fond is upon discovery of a poorly conceived database schema. It is quite simple to redesign and build up as if it was in place on day one utilizing a likeness to the above code snippet. In the same vein, imagine two separate applications needing access to the same data but having very different business models. Instead of each application consuming a schema that makes sense for only one (or neither due to compromise), each has its own model serving its own needs. Since neither is the canonical store of the data, duplication of data isn’t something to be frightened.

One thing to note as the discussion moves into scalability is that employing a denormalized schema design enabled by ES already increases our ability to scale. When intersection of sets (sql joins) is unnecessary, queries against relational data sources perform much faster.

At this point, I have posted three articles, an introduction on how I got to where I am now, a discussion of CQRS, and now a discussion of ES. I’d like to come full circle and discuss how CQRS + ES can be used to achieve further scalability, but first I need to address Brewer’s CAP Theorem and how it forms the backbone of many design decisions related to scalability.