How Spanner achieves global external consistency

What's really being asked

This checks whether you understand the hard part of a globally distributed SQL database: ordering transactions consistently across regions despite clock skew, and the specific mechanism Spanner uses.

The full answer

TrueTime is Spanner's clock API. Instead of a single timestamp, it returns an interval with an explicit uncertainty bound, guaranteeing the true time lies within that window. It is backed by redundant GPS receivers and atomic clocks in every datacenter, keeping the uncertainty small, typically single-digit milliseconds. When Spanner commits a write transaction, it picks a commit timestamp and then performs a commit-wait: it deliberately waits until TrueTime guarantees the chosen timestamp is now in the past everywhere. This ensures that if transaction T1 commits before T2 begins, T1's timestamp is strictly smaller, which delivers external consistency, the strongest form, equivalent to a single global serial order. Each data shard is replicated across zones using Paxos, so a majority of replicas agree on each write, providing fault tolerance and consistent reads.

The mistakes people make

Saying ordinary NTP clocks are enough; they have unbounded skew and no uncertainty guarantee. Confusing external consistency with eventual consistency. Forgetting the commit-wait step, which is what actually converts bounded uncertainty into a correct ordering.

What usually comes next

What does commit-wait cost in latency. How does Paxos fit in. What is the difference between external and strict serializability. What happens if TrueTime uncertainty grows.

A concrete example

Two transactions on accounts in different continents must be globally ordered. Spanner stamps the first commit, waits out the few milliseconds of TrueTime uncertainty, then acknowledges. The second transaction, starting afterward, is guaranteed a later timestamp, so a reader anywhere sees them in the correct order.