A rate is a mean, not a schedule
1000 requests a second says that the expected count in a one-second window is 1000. It says nothing about any particular second, and the counts in consecutive seconds vary by tens without anything having gone wrong.
“A thousand requests a second” is a mean, not a schedule. Chop the second into n opportunities each of probability m/n and the count is binomial; let n grow and it becomes P(k) = e^(−m)m^k/k!, whose variance equals its mean. The burst headroom a system needs is P(count > C).
Core ideas
One distribution, reached from the binomial you already have, and one consequence of it that decides how much headroom a queue needs.
1000 requests a second says that the expected count in a one-second window is 1000. It says nothing about any particular second, and the counts in consecutive seconds vary by tens without anything having gone wrong.
Chop the window into n opportunities, each carrying an arrival with probability m/n. The count is Binomial(n, m/n) with mean m, exactly. As n grows the binomial's probabilities converge to e^(−m)m^k/k!, and no density or integral is needed to say so.
The binomial's variance is m(1 − m/n), which climbs to m as the chopping gets finer. A standard deviation of √m means the relative burstiness of a big stream is smaller than that of a small one: 1000 ± 32 is a 3% wobble, while 10 ± 3.2 is a 32% one.
The material
The binomial, its limit, the variance that follows, and the capacity a burst target buys.
Fix a window and let m be the expected number of arrivals in it. Divide the window into n equal opportunities, each carrying one arrival with probability m/n. The count X is binomial, P(X = k) = C(n,k)(m/n)^k(1 − m/n)^(n−k), and its limit as n grows is the Poisson count P(X = k) = e^(−m)m^k/k!.
Both columns are available at once, which is unusual and useful: the binomial is exact arithmetic on fractions at any n, and the Poisson is the shape it is heading for. The lab draws them over each other so that the limit is something you watch rather than something you accept.
The two tails differ in the third decimal place at n = 200, and the difference is not noise: the binomial genuinely has a slightly smaller variance, because a chopped window can hold at most n arrivals while a Poisson count has no upper bound at all. Chop it finer and the two converge.
The design question is rarely “what is the mean”. It is “how much must this window hold so that it overflows no more than one time in a hundred”, and that is a tail: the smallest C with P(count > C) ≤ target.
Sizing at the mean is therefore not a conservative choice or even a neutral one: it overflows about two windows in five. The three extra arrivals between 15 and 18 are the difference between overflowing 4.4% of the time and 1% of the time, which is what buying the tail costs.
The √m scaling cuts the other way for large streams. A service taking 1000 a second has a standard deviation of about 32, so 1100 is over three standard deviations out; a service taking 10 a second is over three standard deviations out at 20. Consolidating ten small streams into one big one does not change the mean load and does reduce the relative burstiness — a first look at the pooling argument that “Many Servers: Pooling, and Erlang C” makes precisely.
Two limits are worth stating plainly. The Poisson column uses e^(−m) summed as a series, so it is rounded and the lab bounds m at 12, where the method still has its digits. The binomial column is exact fractions and has no such bound; it is capped only by how fine a chopping stays readable, since exactness at n = 20m already means denominators of hundreds of digits.
Interactive
The count in a window, and the headroom its spread costs
Method
Everything here is a tail. The mean is the input, not the answer.
m is a count, not a rate: a rate of 1000 a second is m = 1000 for a one-second window and m = 100 for a hundred-millisecond one. The window has to be named before anything else is true.
One window in a hundred, one in a thousand. This is a business decision and it is the only free parameter; everything downstream follows from it.
Walk C upward and read P(count > C) at each step. The lab does the search and prints the answer; doing it by hand once shows how flat the tail is in that region.
C = 18 at m = 10 is 80% headroom. The same target at a much larger m needs proportionally less, because the spread grows like √m while the mean grows like m.
One mean, one capacity, and the two tails computed both ways so the difference between exact and rounded is visible.
Capacity 15 is 50% above the mean and still overflows one window in twenty-two. Capacity 18 is 80% above it and overflows one in a hundred. That steepness is the whole reason burst headroom is bought explicitly rather than assumed.
For a faded rehearsal, keep the target at one window in a hundred and set m = 5. The supplied first move is that the answer must be above 5 and that the relative headroom will be larger than it was at m = 10, because the spread scales as √m and the mean does not. Predict the capacity, then read it off.
You should be able to build the count in a window as a binomial, say what it becomes in the limit and why, compute P(count > C) both ways, and size a capacity to a stated overflow target rather than to the mean.
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.