Google: bigtable and spanner
Two systems built for different guarantees: Bigtable scales structured storage across machines; Spanner adds globally distributed, externally consistent transactions.
The idea
Bigtable and Spanner are useful to study together because they solve different problems. Bigtable gives applications a sparse, distributed map whose rows are ordered by key; tablets split that key range across servers, and an immutable-file storage design makes writes and compaction explicit. It trades relational querying for control over data layout and scale.
Spanner keeps automatic sharding and synchronous replication, then adds a relational model and externally consistent transactions across regions. Its time API exposes clock uncertainty so the system can decide when a transaction's timestamp is safe. That guarantee has a cost: coordinating a write across replicas can add latency.
The published papers describe Google systems, not questions Google is known to ask in interviews. Use them to practise the underlying choices: data partitioning, replication, transaction guarantees, and the latency each guarantee costs.
Read the originals
Written by the engineers who built it.
- Spanner: Google's Globally-Distributed Database
James C. Corbett and others · Paper, 2012
The OSDI paper explains Spanner's automatic sharding, synchronous replication, external consistency, and the time API that makes globally ordered transactions possible.
- Bigtable: A Distributed Storage System for Structured Data
Fay Chang and others · Paper, 2006
The original account of Bigtable's row-key data model, tablet partitioning, immutable storage files, and the trade-offs behind serving very large structured datasets.
Is this an actual Google interview question?
No. This case study explains published engineering work; it does not claim that Google asks this exact system in interviews. Use the source and linked exercise to practise the design decisions, constraints, and failure cases that transfer to unfamiliar interview prompts.
Practise it
Make the decisions yourself, then compare.
- Sharding Postgres while it is runningShard a Live Database Without DowntimeBuilt from how Notion sharded Postgres while millions of people were using it: choose a shard key, choose a shard count you can live with for years, move every row while writes continue, prove the copy is right, and grow again later without starting over.Advanced · 50 min9 stages
- Storing trillions of chat messagesDesign Discord's Message StorageBuilt from what Discord's engineers published about storing billions, then trillions, of messages: choose a partition key that keeps every read small, survive a channel full of deletions and a channel everyone opens at once, then move the whole thing to a new database while it is running.Advanced · 45 min9 stages
- A look-aside cache at Facebook's scaleDesign a Distributed Cache (Memcache)Built from Facebook's paper on scaling memcache: a look-aside cache serving billions of reads a second, Reads are fast; the hard parts are stale values, stampedes on popular keys, dead servers and invalidations that have to cross regions.Advanced · 50 min9 stages