Adding replicas buys read capacity and nothing else. N copies serve N× the reads, accept 1× the writes however many you buy, apply N× the write work and hold N× the bytes. What a real mixed workload gains is 1/(w + r/N), and the ceiling on that is 1 + ρ — a property of the read/write ratio rather than of the fleet, which is why a write-heavy service gets nothing from replication and pays N times for it.
Core ideas
Three sentences, and the third decides whether the replication factor was worth buying at all.
A copy that skipped a write would not be a copy. So each write is applied N times, once per replica, and the rate at which the cluster can accept writes is exactly the rate at which one machine can apply them — 1×, at N = 3 and at N = 30. The N× that replication is sold on is the read side and only the read side.
Reads can be served by any replica that holds the data, so N replicas serve N times the reads of one. That is a genuine multiplier and it is the reason to replicate. It is also the only one of the four numbers that moves in your favour: the write work and the storage move against you at exactly the same rate.
If a fraction w of operations are writes and r = 1 − w are reads, the cluster does 1/(w + r/N) times the work of one machine. Send N to infinity and the reads cost nothing, leaving 1/w = 1 + ρ. At nine reads per write that ceiling is 10×; at one read per write it is 2×; at zero reads it is 1×. No number of replicas raises it, because every replica still applies every write.
The material
The four multipliers, the speed-up a real mix actually gets, and the ceiling that no fleet size reaches.
A replication factor of N keeps N complete copies of the data. Against a single machine it multiplies read capacity by N, write capacity by 1, write work by N and storage by N. The first is the benefit; the other three are the bill.
The asymmetry is not an implementation detail that a better design removes. It follows from what a replica is. A read is answered by one copy, so copies divide the read stream between them; a write must reach every copy, so copies multiply the write stream instead.
Neither of the first two columns is what the cluster serves, because a real workload is a mix. The read capacity is what you would get if every operation were a read, and the write capacity is what you would get if every operation were a write. The mix decides where between them you land.
The shape is the one Scaling Laws and Cost will name: a serial part that no amount of parallelism divides. Here the serial part is the write, and it is serial in a precise sense — every machine does all of it. Three replicas at nine reads per write reach 2.5× of a possible 10×, and the remaining nine machines in the world cannot close that gap.
At ρ = 0 — every operation a write — w = 1, so speed-up(N) = 1/(1 + 0) = 1× at every N, and the ceiling 1 + ρ is 1× as well. Three replicas serve exactly what one served, for three times the storage and three times the write work. This is not a corner case: an append-only ingest path, a metrics writer or an audit log can sit very close to it, and replicating one of those buys durability and availability and no throughput whatsoever. Those are good reasons to replicate. They are not this reason.
So the honest report of a replication factor is four numbers and a ratio, not one number. “We tripled the replicas” is a statement about the storage bill; whether it is also a statement about throughput depends entirely on ρ, and ρ is a measurement of the workload that Capacity Estimation already taught you to take.
Interactive
Four multipliers, and the read/write ratio that caps the third
Method
The ratio comes first. Every number after it is arithmetic, and every argument about whether replication helped is really an argument about ρ.
ρ is reads per write on the workload you actually have, not the one in the design document. A cache in front of the database removes reads and lowers ρ, which lowers the ceiling; a fan-out that turns one user action into twenty reads raises it. Take this number from a trace.
N× reads, 1× writes, N× write work, N× storage. Keeping them apart is what stops the read multiplier from being quoted as though it were the cluster's.
1/(w + r/N) against 1 + ρ. Two numbers, always together: the second says how much of the possible gain the first one is, and how much buying more machines could ever add.
N times the bytes and N times the write applications are paid whether or not the reads arrived. If the speed-up is 2.5× for a 3× bill, say so; that may still be the right trade, but it is a trade and not a win.
One machine serves a thousand operations a second. The workload is nine reads for every write. Two more machines are added. The question is what each of the four currencies did.
Two and a half times the work for three times the storage and three times the write applications. That is a defensible trade and it is not the 3× the replication factor suggests, because a tenth of the operations were never going to divide.
The last line is the one that changes decisions. Going from three replicas to twelve — four times the fleet — takes the speed-up from 2.5× to about 5.71×, a little over double, and the ceiling is still 10×. Replication is subject to diminishing returns that are set by the workload, and the way to raise the ceiling is to change ρ, which means caching or batching the writes, not buying machines.
For a faded rehearsal, take the same service at ρ = 2 reads per write. The supplied first move is w = 1/3, so the ceiling is 3×. Compute the speed-up at N = 3 and at N = 12, say what fraction of the ceiling each reaches, and state the storage bill beside each before you check them in the lab.
You should be able to state the four multipliers for a given N without hesitating, compute 1/(w + r/N) and the ceiling 1 + ρ beside it, say what a write-only workload gains from replication, and name the storage and write-work bill in the same sentence as the throughput gain.
Something to change about this lesson? Write it down, tick it off when it is handled, and export the list when you want to act on it. Kept in this browser only: nothing is sent anywhere, and nobody is notified.
No recommendations yet for this lesson.