The Problem with Clocks
In a distributed system, you cannot trust clocks. Server A's clock might be 500ms ahead of Server B's clock due to clock drift — a natural phenomenon where hardware clocks gradually diverge from true time. This makes ordering transactions across servers unreliable. If Transaction T1 commits on Server A at timestamp 10:00:00.100 and Transaction T2 commits on Server B at timestamp 10:00:00.050, which actually happened first? Without a reliable global clock, you cannot know.
Traditional distributed databases work around this using logical clocks (like Lamport timestamps), which track causal ordering but don't reflect real-world time. This limits the kinds of consistency guarantees you can make.
Throwing Hardware at the Problem
Google's solution was TrueTime. They deployed GPS receivers and atomic clocks in every one of their datacenters. GPS satellites carry atomic clocks synchronized to within nanoseconds of each other, and atomic clocks are the most accurate timekeeping devices humans have built.
TrueTime doesn't give an exact time. Instead, it exposes an API that returns an interval: [earliest, latest]. It guarantees that the actual, true current time is somewhere inside that window. By using advanced hardware and careful engineering, Google keeps this uncertainty window incredibly small — typically less than 7 milliseconds globally.
TT.now() → { earliest: T - ε, latest: T + ε }
TT.after(t) → true if t has definitely passed
TT.before(t) → true if t has definitely not yet arrived
Commit Wait
To guarantee consistency, when a write transaction commits, Spanner assigns it a timestamp and then forces it to wait until TT.after(commit_timestamp) returns true — meaning the entire uncertainty window has passed. Only then does it report success to the client.
This "commit wait" (typically ~7ms) ensures that if Transaction T1 commits before Transaction T2 starts, T1's timestamp is guaranteed to be numerically less than T2's timestamp. This is how Spanner achieves external consistency (also called linearizability) globally — a guarantee that no other distributed database had achieved at this scale.
The trade-off is that every write incurs a minimum ~7ms latency penalty. For most applications this is acceptable; for ultra-low-latency trading systems, it may not be.
Key Point: TrueTime exposes clock uncertainty as a bounded interval, and Spanner uses commit wait to ensure global transaction ordering. This is the core insight that makes Spanner's consistency model possible — and it required Google to deploy specialized hardware in every datacenter to make it work.