Google Spanner: Buying Consistency With Time
also called TrueTime, External Consistency
Spanner achieves globally consistent transactions by bounding clock uncertainty with dedicated hardware and deliberately waiting out that uncertainty on commit.
The problem
Distributed transactions across regions require agreement on ordering — which transaction happened first. Ordinary machine clocks cannot supply that, because they drift and disagree by amounts that are unbounded and unknown. This is why distributed systems traditionally use logical clocks, which establish causal order but not real-time order, or abandon cross-region transactions entirely.
What they did
Spanner's TrueTime API does something unusual: rather than returning a timestamp, it returns an interval — the earliest and latest the true time could be — with the uncertainty bounded by infrastructure. Google deployed GPS receivers and atomic clocks in their data centres specifically to keep that bound small.
The mechanism that turns bounded uncertainty into correctness is commit-wait. When a transaction commits, Spanner deliberately waits until the uncertainty interval has passed before making the commit visible. That wait guarantees that any transaction starting afterwards is genuinely later in real time, which gives external consistency — the strongest guarantee available — across a globally distributed database.
The trade-off
Commit-wait is added latency on every write, proportional to the clock uncertainty bound. That is the cost, paid deliberately and continuously: Google spends latency to buy consistency, and spends money on specialised hardware to keep the latency small.
It also depends on infrastructure most organisations do not have. The approach is not portable to a system running on commodity cloud instances with ordinary NTP, where clock uncertainty is orders of magnitude larger and the wait would be prohibitive.
The transferable lesson
Two points, and the second is the more useful one.
Time is not a free coordination primitive. Any distributed design that relies on comparing timestamps from different machines — last-write-wins conflict resolution, lease expiry, ordering of events — is relying on an unbounded and unknown error. That is the root of a great many subtle bugs, and it is why fencing tokens and version vectors exist.
Strong consistency is purchasable, and the price is latency. PACELC's "else" clause made concrete: even with no partition, consistency costs coordination, and coordination costs time. Spanner does not evade the trade-off; it pays it explicitly and optimises the price.