A database is CPU-bound on writes, and someone proposes adding three read replicas. It is a reasonable instinct, because replicas fixed the last capacity problem. They will not fix this one.
Replicas copy, they don't divide
Replication solved a read problem. Every replica holds a full copy, so you can keep adding readers until the leader's replication bandwidth gives out. What replication cannot do is make the dataset smaller or the write rate lower, because every replica does every write. Ten replicas do not give you ten times the write throughput. They give you ten copies of the same write throughput.
Replicas still earn their place: they add read capacity and a failover target. But short of making each write cheaper, raising the write ceiling means splitting the data so that each machine owns part of the writes.
Three ceilings, usually in this order
| Ceiling | The symptom you actually see |
|---|---|
| Write throughput | Replication lag grows during peak and never fully drains; followers fall behind and your read-your-writes window widens |
| Dataset size | The working set stops fitting in RAM, and query latency steps up sharply because reads start hitting disk |
| Operational blast radius | Every maintenance action, whether an index build, a major version upgrade or a restore, touches 100% of your customers at once |
Partitioning splits the data so that each machine owns a disjoint subset. Writes divide, storage divides, and maintenance can be done one shard at a time.
Engineering Insight
That is the whole gain, and the course is blunt that everything else in this part of the course is the bill: choosing the key, the tenant that is 40% of your traffic, what moves when you grow, keeping track of where each key lives, resharding while live, secondary indexes, and work that crosses shards.
