Turning a population into requests per second is one multiplication and one division, and the division is where estimates go wrong. A day is 86 400 seconds; everyone divides by 10⁵ instead. That shortcut is worth having and it is not free: the shortcut day is 125/108 of a real one, and the rate it produces lands 13.6% low — which is not the same percentage, and not in the direction most people quote it.
Core ideas
The arithmetic is a division. What the lesson is about is which way up the division goes, and what happens to the answer when the divisor is rounded to a power of ten.
10⁹ req/day ÷ 86 400 s/day = 11 574.074 req/s: the day cancels and s moves to the denominator. Multiplying instead would give req·s/day², which is not a unit anybody wants and is the visible symptom of the most common error in this arithmetic. Writing the unit on every row costs a few characters and makes a wrong-way division impossible to miss.
The shortcut replaces 86 400 with 10⁵, which is a day 125/108 as long. The same daily volume spread over a longer day arrives more slowly, so the shortcut rate is the reciprocal fraction of the truth: 108/125. 10⁹ requests a day is 11 574.074 per second exactly and 10 000 per second through the shortcut, and 10 000 is the smaller of the two, every time, for every input.
125/108 is 15.74% more than one and 108/125 is 13.6% less than one, and both describe the same shortcut. The day is 15.74% too long; the rate is 13.6% too low. The reason they differ is that a percentage is not symmetric under taking a reciprocal, and quoting the first figure as though it applied to the rate is the error this lesson is really about.
The material
The chain that gets the units right, the shortcut everyone uses, and the two exact fractions that say what it costs.
A rate is a quantity per unit of time. To convert a volume per day into a rate per second, divide by the number of seconds in a day: req/day ÷ (s/day) = req/s. The seconds-per-day figure is a conversion factor and appears in the denominator, whichever direction feels natural.
Start from a population. Daily active users times actions per user per day is a volume per day; the division by seconds is the last step and not the first. Doing it in that order means the intermediate figure — requests per day — is itself worth reading, and it is usually the number you can check against something somebody measured.
86 400 is 60 · 60 · 24, and there is nothing approximate about it. What is approximate is what almost everybody does with it, which is to divide by 10⁵ because a power of ten can be done in the head while standing at a whiteboard. The shortcut is good practice. The lesson is that it has a size and a direction, and both are exact fractions.
The shortcut day is 10⁵ seconds. Its ratio to a real day is 10⁵/86 400 = 125/108, so the shortcut day is 15.74% longer than a real one. A rate computed by dividing by it is 108/125 of the true rate, which is 13.6% low.
108/125 is 0.864 exactly, which is the pleasant part of this shortcut: the correction is a two-digit decimal. A rate computed the fast way, multiplied by 0.864, is the rate computed the slow way, and the lab prints both columns so the correction can be checked rather than remembered.
The daily volume is 10⁹ requests. Divided by 86 400 that is 11 574.074 requests a second; divided by 10⁵ it is 10 000 requests a second, which is a number you can hold in your head for the rest of the meeting. The ratio between them is 125/108, and reading the chain back upward — 11 574.074 req/s × 86 400 s/day — returns 10⁹ requests a day, which is where it started.
If a quantity is 15.74% too large, its reciprocal is not 15.74% too small. 1/1.157407… = 0.864, a shortfall of 13.6%. This is not a subtlety about rounding; it is the same asymmetry as a factor of two being +100% upward and -50% downward, seen at a smaller scale. Both are exact fractions — 17/108 and 17/125, which the lab prints as the percentages 425/27% and 68/5% — and they have the same numerator over different denominators, which is a compact way to see that they cannot be equal.
Which one you want depends on what you are correcting. Going from the shortcut rate to the true rate, multiply by 125/108. Going from the true rate to the shortcut rate, multiply by 108/125. The lab labels the two columns by what was divided by, not by which is right, because both are right about their own question.
Usually it does not. An estimate whose factors are known to ±2× carries a range 64× wide, and a systematic 13.6% is invisible inside it — that is the argument for the shortcut, and it is a good one. What the width does not license is forgetting the bias is there.
So the rule is the ordinary one for any approximation: use it, and say you used it. “About ten thousand a second, on the 10⁵ day, so call it twelve thousand if you want the real one” is a complete sentence and takes no longer to say.
Interactive
Per day to per second, one rate into two, and bytes into bits
Method
Volume per day first, seconds last, and the unit written on every line.
users × actions/user/day gives actions/day, and the units cancel on the page rather than in your head. Nearly every wrong capacity estimate is a unit error, and this is the step that catches them while they are still cheap.
Requests per day is the figure most likely to be checkable against something real — a log line count, a billing report, a number somebody quoted last quarter. Reading it out before dividing is free and occasionally ends the estimate early.
86 400 if the number is going into a document, 10⁵ if it is going into a conversation. Either is fine; leaving it unsaid is not, because the two answers differ by a factor the reader cannot recover from the result alone.
Shortcut rate to true rate is ×125/108. True rate to shortcut rate is ×108/125 = ×0.864. If you can only keep one of them, keep 0.864: it is exact, it is two digits, and it is the one that undoes the shortcut you actually used.
Dividing an interval by a positive constant divides both ends by it, so a daily volume known to ÷8 … ×8 is a rate known to ÷8 … ×8. The conversion changes the units and the width of the answer not at all.
Both routes through the same chain, side by side, and the exact fraction between them.
The last line is the one that catches a wrong-way division. Multiplying the rate back by the seconds in a day has to return the daily volume you started from; if it returns something a factor of 86 400² away, the division went the wrong way up and the units would have said so.
Notice that 15.74% and 13.6% both describe this one shortcut. The first is about the day and the second is about the rate, and the lab prints them on separate tiles with separate labels for exactly that reason.
For a faded rehearsal: a service has 5·10⁶ daily users doing 20 actions each. The supplied first move is the daily volume, 10⁸ requests a day. Produce both rates, predict their ratio before computing it, and then say what the shortcut rate would have to be multiplied by to recover the true one. Check all three against the lab by setting the two sliders.
You should be able to take a user count and an actions figure to a rate in one chain with units on every row, quote both the 86 400 and the 10⁵ answers, say which of 15.74% and 13.6% applies to which quantity, and name a situation where the shortcut would actually mislead someone.
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.