Sanity-Checking a Number Someone Published

Why this matters

You will read a throughput number this week — in a blog post, a vendor deck, a conference talk, a job description, or somebody's system-design interview answer. Most of them are true and mean something different from what you assumed. A few are nonsense. The six tasks before this one have given you enough arithmetic to sort them, and the habit of running that arithmetic in ten seconds is worth more than any individual formula, because it changes how you read. The single biggest source of inflated numbers is not lying; it is the denominator. DNS queries, CDN edge hits, origin hits, page views, API calls and internal RPC calls are six different things, and the biggest one wins the headline. A service handling fifty thousand page loads a second, each fanning out to twenty backends, can say a million requests a second with a perfectly straight face. The second biggest source is peak-versus-mean, and the third is amortisation across a fleet or a global anycast footprint that the sentence never mentioned. Learning to ask which layer, counted where, across how many machines, at peak or on average is not cynicism. It is the only way to make a published number useful for your own planning rather than intimidating.

Demo

Two directions. Forwards: turn a headline volume into a mean rate, and then into a plausible peak, which usually shrinks the number dramatically. Backwards: take a claim and ask what it implies about the hardware, then check whether that implication is physically possible.

# plausible.py — can this published number possibly be true?
SECONDS = {"day": 86_400, "month": 2_592_000, "year": 31_536_000}

def mean_rps(volume, per):
    return volume / SECONDS[per]

claims = [
    ("10 billion API calls a day",     10e9, "day"),
    ("209 million page views a month", 209e6, "month"),
    ("2 trillion DNS queries a day",   2e12, "day"),
]
for label, volume, per in claims:
    m = mean_rps(volume, per)
    print(f"{label:>32}: {m:>12,.0f} rps mean | ~{m * 2.5:>12,.0f} rps at peak")
#      10 billion API calls a day:      115,741 rps mean | ~     289,352 rps at peak
#  209 million page views a month:           81 rps mean | ~         202 rps at peak
#    2 trillion DNS queries a day:   23,148,148 rps mean | ~  57,870,370 rps at peak

# Now the reverse direction: what does a claim IMPLY about the hardware?
def implied(rps, boxes, cpu_us, resp_bytes, packets_per_req=4.5, vcpu=32):
    per_box = rps / boxes
    return {
        "rps/box":        per_box,
        "cpu us/req avail": vcpu * 0.60 / per_box * 1e6,
        "Mpps/box":       per_box * packets_per_req / 1e6,
        "Gbps/box":       per_box * resp_bytes * 8 / 1e9,
        "cores needed":   rps * cpu_us / 1e6,
    }

# "We serve a million requests a second on two servers."
for k, v in implied(1e6, 2, cpu_us=79, resp_bytes=2048).items():
    print(f"{k:>18}: {v:>12,.1f}")
#            rps/box:    500,000.0
#  cpu us/req avail:         38.4   <- proxy or cache territory, not a database
#          Mpps/box:          2.2   <- needs multi-queue RSS and a tuned kernel
#          Gbps/box:          8.2   <- fine on a 25 Gbps card
#      cores needed:         79.0   <- but they claim 64 vCPU total. Contradiction.

Try it yourself

1. Take one published number you actually believe, from an engineering post you have read, and run it through mean_rps. Write down the mean and the implied peak. Most headline figures shrink by more than an order of magnitude once they are per-second.
2. For that same claim, find how many machines or locations it is spread across — the post usually says, or you can count points of presence on the company's status page — and divide. If the per-box rate exceeds about a million requests per second for anything doing real work, find what is being amortised: anycast, a cache hit rate above 99 percent, or a different definition of request.
3. Multiply that claim's rps by a guessed response size and check the implied egress against the per-GB rates from the money task. If the answer exceeds the company's plausible revenue, the responses are tiny or the traffic is edge-cached. Work out which, and you have learned more about their architecture than the post told you.
4. Read the same company's numbers from two posts several years apart and compute the implied annual growth rate. A claim implying sustained growth above roughly 2x per year is usually a change in what is being counted, not in traffic.
5. Open radar.cloudflare.com, pick your own country, and compare its published peak hour against the diurnal shape you built from your own logs in the previous task. If they disagree, your audience is not who you think it is — and that changes your capacity plan more than any tuning will.

References

• Nick Craver — Stack Overflow: the architecture (with real traffic figures)
• Let's Encrypt — published issuance and validation statistics
• Cloudflare Radar — published internet-scale traffic data
• Discord — handling two and a half million concurrent voice users