The Global Database
Google faced a problem that no existing database could solve: they needed a single database that could run across hundreds of datacenters globally, handle petabytes of data, serve millions of requests per second, and guarantee strong external consistency — meaning if Transaction A commits before Transaction B starts, every node in the world will observe that ordering. No existing solution could do all of this simultaneously.
So in 2012, they published a paper describing Spanner, the database they built internally. It became one of the most influential systems papers in distributed computing history.
Key Architectural Pillars
1. Sharding by Range
Data is automatically split into units called tablets based on key ranges. If your user table has keys 1–1,000,000, Spanner might split it into tablets covering 1–100,000, 100,001–200,000, and so on. These tablets are distributed across many servers. As data grows, tablets are automatically split and redistributed — no manual resharding required.
2. Replication via Paxos
Each tablet is replicated to multiple servers, often across different geographic zones, for high availability. To keep these replicas consistent, Spanner uses the Paxos consensus algorithm. Paxos works like a voting system: a write is only committed when a majority of replicas (a quorum) agree to accept it. If one replica goes down, the others continue operating as long as a majority remains.
3. Geo-Partitioning
You can control where data physically lives. A company might instruct Spanner to keep U.S. user data in U.S. datacenters and E.U. user data in E.U. datacenters. This serves two purposes: regulatory compliance (GDPR requires E.U. citizen data to stay in the E.U.) and lower read latency (users read from nearby replicas).
But the real secret sauce is how Spanner handles time — which is the subject of the next concept.
Key Point: Spanner's architecture combines range-based sharding, Paxos replication, and geo-partitioning to achieve global consistency. The system is designed so that the database — not the application — handles the complexity of distributed coordination.