Spanner & Global Consistency

What Spanner solves

Most globally distributed databases force a trade-off: strong consistency vs low latency writes everywhere. Spanner targets external consistency — transactions appear in an order consistent with real-time precedence — using TrueTime.

Architecture (skim)

• Data sharded into Paxos groups (each group = replicated log via Multi-Paxos)
• Placement controls which datacenters hold replicas
• Two-phase commit across Paxos groups for distributed transactions
• TrueTime API returns [earliest, latest] wall-clock interval with bounded uncertainty

TrueTime in one paragraph

GPS + atomic clocks bound clock skew. Before commit, Spanner waits out the uncertainty window so commit timestamps reflect real-time ordering. If event A finishes before B starts (in real time), A's commit timestamp < B's.

Commit wait — intentional latency tax for consistency.

External vs serializable

• Serializable — some total order exists
• External consistency (linearizable transactions) — that order respects real-time; stronger for globally visible systems

Interviewers at Google-adjacent loops often ask: "Why can't everyone just use NTP?" Answer: NTP skew is unbounded; Spanner waits until uncertainty is provably small enough.

Failure modes to mention

• Clock jump — if uncertainty bounds are wrong, consistency guarantees break (operational clock sync is critical)
• 2PC coordinator failure — participant recovery via Paxos logs
• Hot tablets — sharding problem, not consistency problem (cross-ref Databases sharding topic)

What to compare in interviews

System	Ordering mechanism	Global strong TX
Spanner	TrueTime + 2PC	Yes
CockroachDB / Yugabyte	HLC + per-range Raft	Serializable (not external)
Cassandra	Tunable quorums	No cross-partition ACID by default

Not required

You don't implement TrueTime or Paxos. You explain why synchronized time changes the CAP conversation and when HLC is the pragmatic substitute.