The Tyranny of the Single Point of Truth
We are taught, from our earliest days tinkering with configurations, to seek a single source of truth. It is the holy grail of system design, the elegant solution to the chaos of drift. A lone, authoritative file, a pristine database, a golden image—this becomes the nucleus around which our entire service orbits. We preach this doctrine with the fervor of the converted. But I want to suggest a heresy: in our quest for this singularity, we often build not a utopia of clarity, but a fragile, silent dictatorship.
The problem isn’t the idea itself, which is born of a noble desire for consistency. The problem is the blind faith we place in it. We assume that because a value exists in one canonical location, it is therefore correct, understood, and immutable. This faith becomes a vulnerability. We stop asking why a setting is what it is. We stop noticing the subtle, incremental changes pushed to that one file. The Single Point of Truth becomes a Single Point of Failure—not of service availability, but of comprehension.
Consider the humble configuration file for a critical but aging service. It is the Truth. A new team member, tasked with a minor change, approaches it with reverence. They see a cryptic timeout value set to 17350. Why? Is it a prime number to avoid collisions? A value from a deprecated hardware spec? A typo from years ago that somehow became gospel? The Truth does not say. It simply *is*. The weight of its authority discourages inquiry. To question it is to question the system's very foundation.
This centralization of truth also centralizes the blast radius of a mistake. A well-intentioned edit, a misplaced character, or an errant script run against the one true file doesn’t just alter a parameter—it rewrites reality for the entire system. There is no redundancy in understanding, no distributed record of intent. The logs might show the change, but they rarely capture the ‘why,’ the rich human context that once surrounded that decision.
Perhaps a more robust, if less elegant, philosophy is to embrace a constellation of truths. A primary configuration file, yes, but accompanied by a rigorous, human-readable changelog that explains the ‘why’ behind every adjustment. Supplemental documentation that lives not in a distant wiki, but as comments in the file itself, treated with the same respect as the code it describes. The goal shifts from maintaining one pristine source to maintaining a clear, auditable narrative.
Truth is not a static artifact to be found and enshrined. It is a story, constantly being revised and retold. Our systems should reflect that. They should be built not just for machines to read without error, but for humans to understand without fear. Let’s dethrone the silent tyrant and build systems that encourage questions, that document their own history, and that distribute understanding as resiliently as they distribute load.
Notes & further reading
A few pages I came back to while writing this: