A Billion Requests a Day Is How Many Per Second
Your API serves 1 billion requests per day.
What's the average requests-per-second — and what number should you actually design for?
Show the conversion, and finish the sizing: how many app servers is that, roughly?
B) ~12,000 RPS average — a scary-sounding scale that a handful of app servers can absorb.
10⁹ requests ÷ 86,400 seconds/day ≈ 11,574 RPS average.
But traffic isn't flat: real products see daily peaks of 2–5× the average, so you design for ~25–60K RPS, not 12K. A tuned stateless app server comfortably handles 5–10K RPS of typical API work, so the compute answer is on the order of 5–15 servers plus headroom — surprisingly small.
That's the real interview insight: at "a billion a day," the app tier is easy. The hard problems are downstream — the database's write path, the cache hit rate protecting it, and hot keys — which is where the discussion should go next.
The rule of thumb to say out loud: 1B/day ≈ 12K RPS average; design for 2–5× peak; and per-day numbers ÷ 100,000 gives a quick per-second approximation (10⁹ ÷ 10⁵ ≈ 10⁴).
Worth naming: p99 latency at peak matters more than average RPS — capacity planning is about the worst hour of the week, not the mean.
Share this question