Database Replication & Sharding
Almost every system design interview reaches the same moment: the single Postgres or MySQL box you drew in the first five minutes cannot keep up. Reads spike because the product got popular; writes spike because you added an event log; the disk fills; a hardware fault takes the whole product down. The two levers you have are replication (copy the same data onto several machines) and sharding (split the data so each machine holds only part of it). They solve different problems, they compose, and each one introduces a new class of bugs that interviewers love to probe.
Replication is primarily about read scaling and fault tolerance: extra copies serve extra reads and survive the loss of a machine, but every copy has to receive every write, so it does not raise the write ceiling. Sharding is about write scaling and data volume: each shard takes a slice of writes and storage, at the cost of losing cheap joins, transactions and secondary indexes across the whole dataset. Almost every large system uses both — a set of shards, each of which is a replicated group.
This subject covers the mechanics and the trade-offs. The consistency-vs-availability framing under network partitions is covered in the CAP Theorem subject; hash rings and virtual nodes are covered in the Consistent Hashing subject; index internals are in Database Indexing; and cross-shard atomic commit protocols belong to the Distributed Transactions & Consensus subject. Here we reference those ideas without re-teaching them.
Why Scale a Database at All?
A single well-tuned relational database on a large machine is more capable than most candidates assume: tens of thousands of simple queries per second, terabytes of storage, sub-millisecond point lookups from cache. Before proposing distribution, be explicit about which limit you are hitting:
| Bottleneck | Symptom | First remedy | Distributed remedy |
|---|---|---|---|
| Read throughput | CPU saturated by SELECTs, connection pool exhausted | Cache, better indexes | Read replicas |
| Write throughput | WAL/fsync bound, lock contention, replication lag climbing | Batch writes, async processing, faster disks | Sharding |
| Storage volume | Disk full, backups and index rebuilds take days | Archive cold data, compress | Sharding |
| Availability | Single machine failure = outage | Backups + restore runbook | Replication with failover |
| Latency by geography | Users far from the datacentre see 150 ms round trips | CDN/cache | Multi-region replicas |
Vertical vs horizontal scaling
Vertical scaling (bigger machine) is the correct first move: no application changes, no new consistency semantics, and cloud providers offer instances with hundreds of cores and terabytes of RAM. Its limits are a hard ceiling (there is a largest instance), a cost curve that becomes super-linear, and zero fault tolerance — one machine is still one failure domain.
Horizontal scaling (more machines) has no ceiling in principle, but you pay in complexity: replication lag, failover, shard-key design, cross-shard queries. The interview answer is not "always shard"; it is "scale vertically and cache until the numbers show a specific bottleneck, then pick the horizontal technique that addresses that bottleneck".