Pattern · seen in 1 breakdown across 1 company

Designated Source of Truth

Definition

When an operation must update several systems that share no transaction — a local store, a durable log, an acknowledgment to an upstream — a crash between any two updates leaves them disagreeing, and distributed atomicity is expensive or unavailable. Instead, designate exactly one of the systems as the source of truth, treat every other system's state as a checkpoint or cache derived from it, and make recovery a reconciliation: on restart, consult the truth and repair the derived states to match. The write path is ordered so the truth is written before anything irreversible depends on it, letting the truth double as a write-ahead log.

The pattern trades transactional machinery on the hot path for repair logic on the recovery path: correctness becomes eventual-on-restart rather than atomic-per-operation, which is a good trade exactly when crashes are rare and the repair is cheap to compute by replay or comparison. Two costs are structural: the designated truth's own availability and durability become the system's deferred failure mode (the one problem the pattern relocates rather than solves), and every derived store must be safely rebuildable — nothing may live only in a checkpoint. Boundary against Atomic Phases: that pattern encloses co-located steps in one real transaction where a shared transactional store exists; this pattern is for when no such store spans the systems involved, and agreement is manufactured by hierarchy instead.

When it applies

01An operation spans systems with no shared transaction (embedded store + message log + consumer offsets; cache + database + index) and crash-consistency between them is required
02One involved system is already durable, ordered, and replayable — a log or journal that can naturally serve as the authority others rebuild from
03Crashes are rare enough, and reconciliation cheap enough, that repair-on-restart beats paying for distributed transactions on every operation

Tradeoffs

Correctness is eventual-on-restart: between a crash and the completed repair, derived stores may disagree with the truth, and everything reading them must tolerate or be fenced from that window
The truth's availability is the deferred failure: when the designated system itself is down or lossy, the pattern has no answer — that residue must be owned explicitly
Every derived store must remain rebuildable from the truth forever; the moment a derived store accumulates state the truth doesn't carry, the hierarchy silently inverts and recovery corrupts

The same move, 1 ways

Every row is a production system that bet on this pattern — the note says how, in that system's own terms.

Segment
Segment Blog
2017
When no single all-or-nothing step can span the RocksDB write, the output-topic publish, and the input acknowledgment, Segment doesn't build distributed transactions; it names one system authoritative. The output topic becomes both the durable log and the final source of truth, RocksDB is demoted to a checkpoint, and on every restart the checkpoint is repaired against the truth. Recovery-by-reconciliation replaces transactions; the cost is that the availability of the source of truth itself becomes the one failure mode the design defers rather than solves. Read the breakdown →

Problems this pattern answers

The walls where its breakdowns live — each opens the cross-company comparison.