How databases scale reads and survive failures — primary-replica, sharding, and consistency trade-offs
A single database server has a ceiling on how many queries it can serve. Replication and sharding are the two primary ways to scale beyond that ceiling. They come with real trade-offs — replication lag, split-brain risk, cross-shard query complexity — that show up directly in day-to-day architectural decisions.
Replication copies the same data to multiple servers. Scale reads by routing to replicas; primary handles all writes. The replica always lags behind the primary — a write isn't visible on the replica until the WAL is applied. This lag is the source of "I just wrote this, why can't I read it?" bugs in applications that read from replicas.
Sharding splits the data itself across multiple servers, each responsible for a subset of rows. Scales both reads and writes, but makes cross-shard joins, transactions, and aggregations much harder.
Read replicas are the first scaling step for read-heavy applications. Route analytics, reporting, and non-critical reads to replicas; route writes and critical reads (e.g., payment confirmations) to the primary. Design applications to tolerate replica lag — don't read-your-own-writes from a replica immediately after writing.