The Truth About Your Source of Truth

As your services scale, single sources of truth can be much harder to define

Photo by Valentin Antonini on Unsplash

Too often when we design our microservices architecture,* we find ourselves wrapped around the axle trying to define a single source of truth (or SoT) for our domain entities. Common wisdom has it that every domain entity in our enterprise should live in exactly one centralized location. If you want to fetch an instance of that entity, you go to that location.

*Note: I loathe the term microservices architecture, but that’s for another discussion.

As with much common wisdom, this isn’t necessarily so. It’s a good idea to keep track of where our data resides, sure. But bending over backward to define a single SoT for every piece of data is the wrong approach. At best, it’s often simply not necessary. Worse, it can cause more problems than it purports to solve. In fact, the very notion runs counter to the event-based systems that power many enterprises today. And as we’ll discuss, a true source of truth for our data is, by and large, mythical.

What’s Wrong With a Single Source of Truth?

Before we get into the problems of single SoTs, let’s revisit why we build microservices in the first place. We’ll start with one of the most fundamental relevant patterns: the bounded context. Much has already been written about the pattern, but the general idea is that each business domain should be thought of as its own self-contained system with judiciously-designed inputs and outputs.

From an organizational standpoint, each bounded context is owned by a single, cross-functional team. The team builds, deploys, and maintains the services and applications that it needs to get its job done — with minimal dependencies on any other teams.

And this leads us to perhaps the most fundamental benefits of a microservices architecture. While we can rattle off the technical benefits of microservices, the true benefits are organizational. Teams have the control and responsibility over their own projects. They can make as many changes to their code as they want to, with little fear of breaking other teams. They can release as frequently as they need, without requiring coordination with…