Blog 19 — Google Spanner: Globally Distributed SQL

C

Qubits of DPK

April 7, 2026

Core Case Studies
Source: https://research.google/pubs/pub39966/
Core Concept: TrueTime API, Global strong consistency, Multi-region transactions, External consistency
Why SDE-2 Critical: Proves global distribution + strong consistency is possible — banks and payment systems increasingly use Spanner-like DBs
Status: Draft notes ready

Quick Revision

  • Problem: Keep SQL transactions globally consistent across regions.
  • Core pattern: TrueTime-backed ordering plus Paxos-replicated shards.
  • Interview one-liner: Spanner buys strong global consistency by combining distributed systems design with specialized time hardware.

️ What Makes Spanner Unique

javascript
QUBITS OF DPK
1Traditional belief:
2  Distributed DB + Strong Consistency = Impossible
3  (CAP theorem → choose 2 of 3)
4
5Spanner proved:
6  Globally distributed across 100+ data centers
7  STRONG consistency (not eventual)
8  SQL interface (relational model)
9  Automatic sharding + rebalancing
10
11How? TrueTime API — atomic clocks + GPS receivers in every data center

Core Concepts

TrueTime API — The Secret Weapon

javascript
QUBITS OF DPK
1The distributed systems problem:
2  Clocks on different machines drift → can't order events globally
3  Machine A thinks it's 10:00:00.000
4  Machine B thinks it's 10:00:00.003  (3ms drift)
5  Which transaction came first? Nobody knows.
6
7TrueTime solution:
8  Each Google data center has:
9  ├── GPS receivers (accurate to 1 microsecond)
10  └── Atomic clocks (stable, doesn't drift)
11
12  TrueTime.now() returns: [earliest, latest] ← an INTERVAL, not a point
13  Guarantees true time is within this interval (±4ms max uncertainty)
14
15  Before committing transaction: WAIT until interval expires
16  → Guarantees all subsequent transactions see this one first
17  → Global ordering without coordination

External Consistency

javascript
QUBITS OF DPK
1If transaction T1 commits before T2 starts:
2  → T2 will ALWAYS see T1's effects
3  → Even if T2 runs on a different continent
4  → This is external consistency (stronger than serializability)
5
6How TrueTime enables this:
7  T1 gets timestamp ts1 (after waiting for uncertainty window)
8  T2 starts after T1 commits → T2 gets ts2 > ts1
9  Any read at ts2 sees T1's writes
10  → Causality preserved globally via timestamps

Architecture

javascript
QUBITS OF DPK
1Spanner is organized as:
2  Universe → Zones → Spanservers
3
4  Zone = one data center (Google has 100+ globally)
5  Spanserver = tablet server (owns 100-1000 data shards)
6
7Paxos groups:
8  Each shard replicated across 5 spanservers in different zones
9  Paxos consensus for every write (majority must agree)
10  Leader elected per shard → handles writes
11  Any replica can serve reads (at consistent timestamp)

Read Modes

javascript
QUBITS OF DPK
1Strong reads:
2  Read at current TrueTime timestamp
3  Must contact Paxos leader → guaranteed to see latest writes
4  Latency: ~5-10ms (local zone)
5
6Stale reads (snapshot reads):
7  Read at timestamp in the past (e.g., 10 seconds ago)
8  Can be served by any replica (no leader needed)
9  Latency: sub-millisecond (local replica)
10  Use for analytics, reporting — don't need absolute freshness
11
12Read-write transactions:
13  Full ACID transaction across multiple shards/regions
14  Uses TrueTime for global ordering
15  Latency: 10-100ms depending on geographic spread

Who Uses Spanner-like Systems

javascript
QUBITS OF DPK
1Google Spanner: Google Pay, YouTube metadata, Ads
2CockroachDB: Open-source Spanner-inspired (uses HLC instead of TrueTime)
3YugabyteDB: Another open-source Spanner-inspired
4Azure Cosmos DB: Microsoft's globally distributed DB
5
6Use cases:
7  ✓ Global payment systems
8  ✓ Multi-region inventory management
9  ✓ Financial ledgers
10  ✓ Any system needing global consistency + SQL

What Spanner Achieved

5 Interview Questions This Blog Unlocks

Q1. Design a global payment system that works across multiple regions

Answer: Use Spanner or CockroachDB. Strong consistency for financial data — can't use eventual consistency for money. TrueTime-based ordering ensures global transaction ordering. Paxos replication for durability. Stale reads for reporting/analytics. Multi-region writes possible with latency tradeoff.

Q2. What is TrueTime and why did Google build it?

Answer: GPS + atomic clocks in every data center. Returns time as an interval [earliest, latest] with max 4ms uncertainty. By waiting for the uncertainty window before committing, transactions get globally ordered timestamps. Eliminates the need for distributed coordination protocols just for time ordering. Only possible with special hardware.

Q3. How is Spanner different from traditional distributed databases?

Answer: Traditional distributed DBs sacrifice consistency for availability (Cassandra, DynamoDB = AP). Spanner provides external consistency (stronger than ACID serializability) while being globally distributed. Achieved via TrueTime — physically synchronized clocks enable global ordering without expensive coordination protocols.

Q4. What is CockroachDB and how does it achieve Spanner-like consistency without atomic clocks?

Answer: CockroachDB uses Hybrid Logical Clock (HLC) instead of TrueTime. HLC combines physical clock + logical counter. Similar external consistency guarantees, slightly more uncertainty. Runs on commodity hardware (no GPS/atomic clocks needed). Open-source Spanner alternative for companies that can't afford Google's infrastructure.

Q5. When would you choose Spanner over Cassandra for a system design?

Answer: Choose Spanner when you need strong consistency AND global distribution: financial systems, payment ledgers, inventory systems where overselling is unacceptable. Choose Cassandra when availability > consistency: social feeds, user activity logs, analytics, any system where eventual consistency is acceptable. Spanner is significantly more expensive.

Key Engineering Lessons