A single request rate is almost never the quantity you want, because reads and writes size different parts of a system. Splitting one rate into two is a line of algebra with one trap in it: a ratio of r:1 counts reads against writes, so the write share is 1/(r+1) and not 1/r. At 100:1 that is the difference between 1% and 0.990099%, which is small, and the habit of being wrong about it is not.
Core ideas
The algebra is two lines. What it is for is the part worth arguing about: the two rates you end up with are consumed by different lessons of this course and by different courses after it.
r:1 says reads divided by writes is r. If W is the write rate then reads are rW, and the total is R + W = (r+1)W, so W = T/(r+1). The +1 is the writes themselves, which are part of the traffic being split and not something outside it. This is the whole content of the arithmetic and it is also the whole misconception.
The write rate is what sizes storage, the replication factor and the durability budget; the read rate is what sizes caches, bandwidth and fan-out. Splitting the total and then sizing both paths off the total again does the arithmetic and throws the result away. At 100:1 the writes are 99.01 a second out of 10 000, and every hard problem on the rest of this path lives in those ninety-nine.
Reading 100:1 as “one percent writes” gives 100 writes a second where the truth is 99.01, an overstatement by 101/100. The error shrinks as r grows and it is nowhere near negligible at small r: at 2:1 the instinct says half the traffic is writes when a third of it is, an overstatement by 3/2.
The material
What a ratio claims, the two shares it implies, and why the split is worth doing at all.
A workload with read rate R and write rate W has read/write ratio r = R/W, usually written r:1. The write share is W/(R+W) and the read share is R/(R+W); the two shares are positive and sum to 1.
The ratio and the shares carry the same information and they are not the same number. A ratio compares the two parts to each other; a share compares one part to the whole. Confusing them is what makes 100:1 sound like 1%, and the conversion between them is exactly the +1 in the denominator.
If R/W = r and T = R + W, then W = T/(r+1) and R = Tr/(r+1). The write share is 1/(r+1) and the read share is r/(r+1).
From R = rW and T = R + W we get T = rW + W = (r+1)W, so W = T/(r+1). Then R = T − W = T − T/(r+1) = Tr/(r+1).
The shares follow by dividing by T, and they sum to 1/(r+1) + r/(r+1) = (r+1)/(r+1) = 1, which is the check worth doing: any pair of shares that does not add to one has been read off the wrong denominator.
□
The two shares adding to one is the check that survives any value of r. The instinct’s pair does not: 1/100 for writes and 99/100 for reads gives a ratio of 99:1, not 100:1. So the fast way to catch this error is to convert back — take your two shares, divide one by the other, and see whether the ratio you started with comes out.
Ninety-nine writes a second against ten thousand requests is easy to describe as noise, and for the read path it is. For everything else on this path it is the whole story. Those writes are what accumulates in “Storage from Ingest and Retention”, what gets multiplied by the replication factor, what has to be ordered and made durable, and what a partitioning scheme has to route consistently. The read path is the one that can be absorbed by a cache; the write path is the one that cannot.
Reads are 9 900.99 a second and writes are 99.01 a second, exactly 1 000 000/101 and 10 000/101. Sizing the storage from the total instead would overstate the ingest by a factor of 101, and sizing the cache from the total instead would overstate the read load by about one percent. The same error in the two directions costs wildly different amounts, which is the practical argument for doing the split at all.
A read/write ratio is measured over a window, and it is a property of that window rather than of the system. A daily figure of 100:1 can be 5:1 during the hour a batch import runs, and the hour that matters for sizing is the busiest one rather than the average one. “Peak to Average” is where that gets a number attached to it; here it is enough to write down which window the ratio came from.
The other thing worth writing down is that the ratio is a ranged factor like any other. A ratio quoted as 100:1 is usually known to a factor of two or three either way, and the write rate it implies inherits that width. The interesting part is that the width is asymmetric in its consequences: a ratio that is wrong by 3× barely moves the read rate and moves the write rate by nearly the same 3×.
Interactive
Per day to per second, one rate into two, and bytes into bits
Method
Ratio to shares, shares to rates, and a check that the pair is consistent.
100:1 is reads against writes, so r = R/W = 100. A ratio with no named direction is not usable, and the failure mode is silent: the arithmetic works perfectly with the two rates swapped and produces a system sized backwards.
Write share 1/(r+1), read share r/(r+1). Check that they add to 1 before going any further; a pair that does not add to one has been built from the wrong denominator and every number after it will be wrong by the same factor.
T/(r+1) writes a second and Tr/(r+1) reads a second. Keep both, with their units, and keep the exact fractions if the numbers are going to be multiplied again — 10 000/101 is easier to carry through a chain than 99.0099.
The write rate goes into storage, retention, replication and durability. The read rate goes into cache sizing, bandwidth and fan-out. If both paths end up being sized from the same figure, the split was not used and did not need doing.
A ratio measured over a day and a ratio measured over the busiest hour are different numbers about the same system, and sizing wants the second one. Writing down which you have is what makes the estimate auditable later.
One rate in, two rates out, with the shares as exact fractions and the instinct’s answer alongside for comparison.
The line worth keeping is the one that converts back. The instinct’s pair of rates, divided into each other, gives 99:1 — not the ratio it started from. That round trip catches the error without needing to remember which of 1/r and 1/(r+1) is correct.
The 1% looks harmless and the lesson is not that it is dangerous. It is that the same mistake at 2:1 says half the traffic is writes when a third of it is, and that a person who has the rule wrong will apply it at whatever r the next system hands them.
For a faded rehearsal: a service does 6 000 requests a second at 5:1. The supplied first move is r + 1 = 6. Produce both shares, both rates, and the factor by which 1/r would overstate the writes; then set the lab’s ratio slider to 5 and check all five figures. Say the overstatement factor before you look at it.
You should be able to turn any r:1 into both shares and both rates, check the pair by converting back to the ratio, say what each of the two rates goes on to size, and state the factor by which 1/r overstates the write rate at any r.
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.