Spanner: Google's Globally Distributed Database
Google's globally distributed SQL database that uses GPS and atomic clocks (TrueTime) to achieve external consistency across continents.
Quick answer: Spanner: Google's Globally Distributed Database
Spanner: Google's Globally Distributed Database is covered here as a practical system design resource. Google's globally distributed SQL database that uses GPS and atomic clocks (TrueTime) to achieve external consistency across continents. Use it as a curated reference while connecting the original engineering lesson to practical system design decisions.
Focus on the problem being solved, the main design choice, the failure mode, and the tradeoff you would defend in front of a senior engineer. This page is part of the DosiBridge system design knowledge graph, so it links related concepts, interview problems, tradeoffs, and references instead of leaving the topic isolated.
Historical Context
Published by James Corbett et al. at Google in 2012 (OSDI), Spanner was the first system to distribute data globally and support externally-consistent distributed transactions. Before Spanner, Google relied on Bigtable for scalable storage and Megastore for cross-datacenter replication, but Bigtable lacked cross-row transactions and Megastore suffered from poor write throughput. Application teams increasingly needed both scale and transactional guarantees, leading Google to build a system that was effectively a "globally distributed, externally consistent, synchronously replicated database."
Core Problem
How can you provide ACID transactions and strong consistency across data centers on different continents without sacrificing availability or horizontal scalability?
Key Innovation
Spanner's breakthrough is the TrueTime API, a clock service that combines GPS receivers and atomic clocks in every data center to provide a bounded uncertainty interval for the current time. Instead of returning a single timestamp, TrueTime returns an interval [earliest, latest] and guarantees the true time falls within it. The uncertainty is typically 1-7 milliseconds.
Spanner uses TrueTime to assign globally meaningful timestamps to transactions. After committing a transaction, Spanner waits out the clock uncertainty ("commit-wait") before making the result visible, ensuring that if transaction T1 committed before T2 started, then T1's timestamp is strictly less than T2's. This property is called external consistency (equivalent to linearizability for transactions), and it means any observer anywhere in the world sees a consistent order of transactions.
Under the hood, Spanner uses Paxos groups for replication. Data is organized into directories (contiguous ranges of rows sharing a common key prefix), and each directory is replicated across data centers via a Paxos group. Cross-shard transactions use two-phase commit coordinated across Paxos groups, with TrueTime timestamps ensuring consistent ordering.
Architecture / Algorithm
- TrueTime API: Returns time as an interval [earliest, latest]. Commit-wait ensures causal ordering.
- Paxos Groups: Each shard is replicated via Paxos; the Paxos leader handles reads and writes.
- Directories: Fine-grained data movement units that can be migrated between Paxos groups.
- Two-Phase Commit: Cross-shard transactions are coordinated with 2PC, made safe by Paxos-replicated participant logs.
- Schema: Semi-relational with SQL support, hierarchical table interleaving for data locality.
Strengths
- External consistency (strongest guarantee) across global data centers
- Full SQL support with ACID transactions at global scale
- Automatic sharding and rebalancing
- High availability via Paxos replication
Weaknesses
- Commit-wait adds latency proportional to clock uncertainty (milliseconds, not microseconds)
- Requires specialized hardware (GPS receivers, atomic clocks) for TrueTime
- Write latency is higher than eventually-consistent systems due to cross-datacenter Paxos
- Extremely complex to build and operate — practically only Google (and now CockroachDB with software clocks) has attempted it
Modern Systems Influenced
Google Cloud Spanner is the public version. CockroachDB adopted Spanner's architecture but replaced TrueTime with hybrid logical clocks (accepting slightly weaker guarantees). YugabyteDB also draws from Spanner's design. TiDB's distributed transaction model is inspired by Spanner. The paper showed the industry that global strong consistency is achievable, shifting expectations for distributed databases.
Interview Relevance
Cite Spanner when discussing globally distributed systems, strong consistency across regions, or the role of time in distributed systems. Know how TrueTime works, why commit-wait is necessary, and the tradeoff of latency for consistency. Compare with Dynamo (AP) to show understanding of the consistency spectrum. Spanner is the gold standard answer for "how would you design a globally consistent database?"
Plain-English Summary
Spanner stores data across data centers worldwide, keeping it in sync using Paxos consensus. It assigns globally ordered timestamps to every transaction using GPS and atomic clocks, then waits a few milliseconds to ensure no other transaction can sneak in with a conflicting timestamp. This gives you the same strong guarantees as a single-machine database, but spread across the planet.
Original DosiBridge notes for Spanner: Google's Globally Distributed Database
This section is written specifically for this page, not copied from a general system-design checklist. The useful way to study Spanner: Google's Globally Distributed Database is to connect the concept to a production service where growth exposes the first weak assumption in the original design. That framing changes the design discussion from definitions to operating choices.
What makes this topic distinct
- Practice Loop: For Spanner: Google's Globally Distributed Database, decide the practice loop before choosing tools; otherwise the design looks clean but fails when spanner changes.
- Implementation Exercise: For Spanner: Google's Globally Distributed Database, decide the implementation exercise before choosing tools; otherwise the design looks clean but fails when spanner changes.
- Review Checkpoint: For Spanner: Google's Globally Distributed Database, decide the review checkpoint before choosing tools; otherwise the design looks clean but fails when spanner changes.
- Failure Drill: For Spanner: Google's Globally Distributed Database, decide the failure drill before choosing tools; otherwise the design looks clean but fails when spanner changes.
- Comparison Target: For Spanner: Google's Globally Distributed Database, decide the comparison target before choosing tools; otherwise the design looks clean but fails when spanner changes.
Production review question
If a team adopts Spanner: Google's Globally Distributed Database, what observable signal proves it helped instead of only making the architecture diagram more fashionable?
Practical metric to track
Track spanner health as a named dashboard or review item: combine one user-facing metric, one saturation metric, and one correctness metric. For Spanner: Google's Globally Distributed Database, this keeps the discussion grounded in behavior that can be measured after deployment instead of generic advice that sounds good in an interview but never gets verified.