Read-only client
Backend & Runtime / Knowledge library
Single Source of Truth
Designates one authoritative representation for a fact within a defined scope
Why learn Single Source of Truth?
It prevents competing copies from diverging
The problem it solves
It gives consumers a clear place to resolve the current accepted value
Where it came from
Single Source of Truth is a software design principle that designates one authoritative representation for a fact within a defined scope. Its guarantees and tradeoffs depend on the concrete implementation and operating context.
Build your understanding
Work through these exercises in order. Try the task before opening a reference.
- Define Single Source of Truth and distinguish it from a neighboring concept.
- Choose a realistic task where Single Source of Truth is appropriate.
- Identify a failure mode caused by misusing Single Source of Truth.
- Interpret a small design or result involving Single Source of Truth.
- Explain one tradeoff or limitation of Single Source of Truth.
Documentation and sources
- Software Engineering at Google (abseil.io)
Connect the ideas
Explore next
Real World Example
Unified Global Inventory Registry
A multinational retail logistics firm managing regional warehouses.
The business problem
Discrepancies between regional databases caused stock-outs and redundant procurement because no single system held the authoritative count for high-value assets.
How this topic solves it
Implementing a Single Source of Truth (SSOT) pattern where a centralized registry service acts as the exclusive authoritative representation for item availability, forcing all regional systems to read from and write to this central node rather than maintaining local state.
- Identify the canonical data entity representing the physical asset state.
- Deprecate local write permissions in regional databases to prevent data divergence.
- Expose a centralized API layer that enforces validation rules before updating the master registry.
- Implement a read-through cache strategy to maintain performance without sacrificing the authoritative nature of the registry.
This diagram illustrates the flow from regional requests to the authoritative registry.
Validation and Auth
Authoritative state
Immutable history
- Regional System → 1:n requests → Registry API
- Registry API → 1:1 updates → Master Registry
- Master Registry → 1:n records → Audit Log
Expected business outcome
Consistent inventory visibility across all regions, eliminating conflicting reports and enabling reliable automated replenishment.
Limitations and checks
The centralized registry introduces a potential latency bottleneck and a single point of failure; monitoring can be performed by tracking the request-to-response time latency metrics of the registry API.