One Service, One Source of Truth

One service, one source of truth does not mean that the data may exist in only one physical place. It means one boundary is authoritative for the business record, the key invariants, and the state transitions that define what is true. Other services may cache, project, enrich, or replicate that data, but they should not quietly become the place where the business meaning is actually decided.

This distinction matters because distributed systems often duplicate data for good reasons. The mistake is not duplication itself. The mistake is losing track of which copy is authoritative.

What “Authoritative” Actually Means

Authoritative ownership usually means:

• one service decides whether a record is valid
• one service enforces the important invariants for that record
• one service owns the official state transitions
• other systems consume or derive from that truth instead of redefining it

For example, a fulfillment service may store a local copy of a shipping address for execution speed, while checkout or customer profile remains authoritative for the address the customer actually confirmed. The same data can appear in more than one place without implying equal authority.

    flowchart LR
	    A["Customer profile"] -->|authoritative address| B["Checkout"]
	    B -->|confirmed shipping address snapshot| C["Fulfillment"]
	    C --> D["Shipment execution"]

What to notice:

• the data appears more than once
• authority and local operational use are not the same thing
• the boundary stays cleaner when teams name the difference explicitly

Why the Phrase Is Often Misunderstood

Teams sometimes hear “one source of truth” and interpret it as “no duplication allowed.” That becomes a problem because distributed systems usually do need local copies for performance, resilience, reporting, or asynchronous workflows. The better interpretation is:

• one source of business truth
• many possible representations or consumers of that truth

This framing is more accurate and more useful in architecture review.

A Small Ownership Declaration

The example below shows a clearer way to describe authority than simply listing where a table exists.

 1record: shipping_address
 2authoritative_service: customer-profile
 3consumed_by:
 4  - checkout
 5  - fulfillment
 6local_copies:
 7  checkout:
 8    purpose: user confirmation flow
 9  fulfillment:
10    purpose: shipment execution
11rule: only customer-profile defines canonical address state

What this demonstrates:

• local copies are acceptable when their purpose is explicit
• authority is about who defines truth, not who stores bytes
• consumers should not silently start writing the canonical record

Where Teams Commonly Get This Wrong

• allowing read models or local caches to become the place where corrections are made
• letting several services write the same business record
• assuming a duplicated field implies shared ownership
• avoiding the word authoritative because it makes the decision feel too explicit

If a team cannot state which service is authoritative, the architecture is usually already carrying hidden ambiguity.

Design Review Question

A reporting system receives events about invoices and later allows analysts to “fix” invoice states directly in the reporting store because it is easier than updating the billing workflow. Does the reporting system remain a non-authoritative consumer?

No. The stronger answer is that the reporting store has started acting like a source of truth. That weakens the billing boundary and creates a dangerous mismatch between official and operational state.

Quiz Time