What We Are Trying to Achieve
Before diving into solutions, it helps to name the goal precisely. The property we want is called External Consistency, also known as Linearizability in academic literature. It is the strongest consistency guarantee a distributed database can provide.
Think of it like a global ledger with a single, authoritative pen. No matter how many servers are involved, the database behaves as if every transaction was written into that ledger one at a time, in the exact order they happened in the real world.
The Formal Rule
If Transaction $T_1$ commits (fully finishes) before Transaction $T_2$ starts — in absolute real-world time — then the timestamp assigned to $T_1$ must be strictly less than the timestamp assigned to $T_2$.
$$T_1.end < T_2.start \implies Timestamp(T_1) < Timestamp(T_2)$$
This sounds obvious. Of course earlier events should have smaller timestamps. But achieving this when $T_1$ runs on a server in New York and $T_2$ runs on a server in Tokyo — with no shared clock between them — is mathematically impossible using standard NTP, which can drift by hundreds of milliseconds in either direction.
Why NTP Alone Fails
NTP synchronizes clocks over the network by measuring round-trip latency and estimating the offset. The problem is that network latency is variable. A packet might take 1ms or 50ms depending on congestion. NTP cannot know exactly how long the packet was in flight, so it cannot correct the clock with perfect precision. The result is a residual uncertainty — typically 50ms to 500ms on commodity hardware — that makes it impossible to guarantee the ordering rule above.
The two major NewSQL approaches — Spanner's TrueTime and CockroachDB's Hybrid Logical Clocks — are fundamentally different answers to the same question: how do you enforce the ordering rule when you cannot trust the clocks?
Interviewers at companies running distributed databases often ask: "What is the difference between linearizability and serializability?" Serializability means transactions execute as if they ran one at a time in some serial order — but that order doesn't have to match real-world time. Linearizability adds the real-time constraint: the serial order must respect the actual wall-clock order of non-overlapping operations. Spanner provides both; it calls the combination "external consistency." CockroachDB also targets this but uses a different mechanism with a slightly different failure mode under clock skew.