Scaling a Database (Replication & Sharding)

When one database box isn't enough: how to scale up and optimize first, scale reads with replication (and live with replication lag), and only then scale writes with sharding - and why sharding is the expensive last resort.

1. The Bottleneck Before you scale out, scale up and optimize: indexes, queries, caching, and connection pooling fix most 'we need to scale' problems. And first figure out whether you're read-heavy or write-heavy - the two have completely different cures.
2. Replication Keep live copies of your database: a leader takes all writes and streams them to followers, which serve reads. This scales reads and gives you failover - but followers can lag behind the leader, so your app must be ready for slightly stale reads.
3. Sharding When writes outgrow one machine, sharding splits the data across machines by a shard key so each shard owns a slice of writes. It scales writes - at a steep cost: choosing the key, cross-shard queries and joins, rebalancing, and losing cross-shard transactions. The clear-eyed last resort.