A support copilot drafts replies for human agents. It handles 1,296,000 tickets per month (treat a month as 30 days) and makes exactly 2 LLM calls per ticket. Traffic peaks at 10x the average during business hours. Estimate (a) the average LLM calls per second and (b) the peak QPS you should capacity-plan for.
Work it in three small steps.
First, count the calls, not the tickets. Each ticket triggers 2 LLM calls, so the month produces 1,296,000 x 2 = 2,592,000 calls.
Second, count the seconds. A 30 day month has 30 x 86,400 = 2,592,000 seconds. The numbers match on purpose: 2,592,000 calls over 2,592,000 seconds is exactly **1 call per second** on average.
Third, apply the peak factor. Support traffic clusters in business hours, and the problem says peaks run 10x the average, so you plan for 10 calls per second.
The takeaway is bigger than the arithmetic. A million-plus tickets a month sounds like a scaling crisis, but it averages out to one call per second, which any provider handles easily. The numbers that actually matter are the peak rate, because that is what you provision and rate-limit for, and later the tokens per second behind each call, because providers meter tokens, not just requests.
Convert the monthly number to a per-second rate, then plan for the peak.
$$\lambda_{avg} = \frac{1{,}296{,}000 \times 2}{30 \times 86{,}400} = \frac{2{,}592{,}000}{2{,}592{,}000} = 1 \text{ call/s}$$
With the stated 10x peak to average ratio, the capacity planning number is **10 QPS**, not 1. Averages describe billing; peaks describe the infrastructure you must stand up, the rate limits you must negotiate, and the queue depth you must absorb.
Two habits make this estimate reliable under interview pressure. Count the right unit first: tickets are not calls, and here the 2x multiplier doubles the answer. And keep the seconds-in-a-month constant handy: 86,400 seconds a day, about 2.6 million a month. Monthly volumes divided by 2.6 million turn intimidating totals into honest per-second rates almost instantly.
The natural follow-up, and worth volunteering, is that QPS alone understates load for LLM systems. Ten calls per second at 3,000 input and 500 output tokens each is 30,000 prefill plus 5,000 decode tokens per second, and provider rate limits are written in tokens per minute as much as requests per minute. The QPS estimate is step one of the capacity chain, not the conclusion.
Quick reference
TL;DR
1,296,000 tickets times 2 calls is 2,592,000 calls; a 30 day month is 2,592,000 seconds, so the average is exactly 1 call per second, and the 10x peak factor makes 10 QPS the planning number.
A bakery brags that it sells two and a half million buns a month. Sounds enormous, until you notice a month has about two and a half million seconds. The bakery sells one bun per second. One oven could nearly keep up.
But customers do not arrive evenly. At lunch rush, ten people line up every second, and at 3 a.m. nobody comes. If the bakery built its kitchen for the average, the lunch line would stretch around the block every single day. So the rule is: divide the big monthly number into a per-second number to see how small it really is, then size the kitchen for the rush, not for the quiet average.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.
Traffic is dominated by scheduled batch jobs rather than user-driven requests Batch workloads are shaped by you, not by users; you size for the batch window and can flatten the peak deliberately.
The workload is brand new with no historical peak to average ratio A guessed 10x can be badly wrong in either direction; launch behind a queue and measure the real ratio before committing to capacity.
A hard launch event or marketing moment is expected Launch spikes are step functions, not multiples of a steady average; plan from expected concurrent users instead of monthly volume.
Quick scan · 2–4 min
Everything important, quickly.
5 min: rehearse the seconds-in-a-month constant, redo the division, then practice the follow-on conversion from peak QPS to tokens per second against a real rate card.
Real-world examples
Real products, models, and research that use this idea.
1OpenAI and Anthropic both publish rate limits in requests per minute and tokens per minute per tier, so converting peak QPS onward into tokens per minute is exactly how teams pick a tier.
2Azure OpenAI provisioned throughput units are sized against peak tokens per minute, making the peak conversion, not the monthly average, the purchasing decision.
3Capacity dashboards in Helicone and Langfuse chart requests per second and tokens per second side by side, reflecting that both meters bind in production.
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QExtend the estimate: each call averages 3,000 input and 500 output tokens. What token throughput must the provider sustain at peak?
Sign in or go Pro to see the approach for this follow-up.
QThe 10x factor is an average over business hours. How do you protect against minute-level bursts above it?
Sign in or go Pro to see the approach for this follow-up.
QWhen does this same arithmetic justify moving traffic to a batch API?
Sign in or go Pro to see the approach for this follow-up.
Don't say this
Red flags and common mistakes that signal junior thinking. Click to expand.
Most common mistake
Dividing tickets instead of calls, or capacity planning on the average. The system must survive business-hour peaks, so the 10x peak number is the one you provision for.