What this estimates
Given how long one request takes and how many instances are handling them, how much total load can the system actually sustain — and does that cover the target you actually need? This is Little's Law, a genuinely proven queueing-theory result (L = λW: the average number of requests in a system equals the arrival rate times the average time each spends in it), rearranged into the form that answers a capacity question directly.
The model
Treat each instance as handling one request at a time — the conservative, fully-sequential baseline. One instance's maximum throughput is then just the inverse of how long each request holds it busy:
capacity per instance = 1 / latency
total capacity = instances × capacity per instance
utilization = target rps / total capacity
instances needed = target rps × latency (Little's Law: L = λW)That last line is worth sitting with: the number of instances a target load needs is exactly the target requests-per-second multiplied by how long each one takes — double either one and you need twice the instances to hold the same throughput.
The one assumption that matters most
"One request at a time per instance" is deliberately the simple, defensible floor — real instances are often not that limited. A Node.js process handling I/O-bound requests asynchronously, or a process with a thread pool, can hold many requests in flightconcurrently on a single instance. If your real setup handles C concurrent requests per instance, get an accurate estimate by entering instances × C in the Instances field instead of the raw instance count — the math is identical, Little's Law doesn't care whether that concurrency comes from separate machines or from one machine juggling many requests at once.
What this doesn't model
- Latency isn't actually constant. This uses one average — real latency has a distribution (and a tail), and queueing systems get measurably worse near full utilization: response times climb non-linearly as utilization approaches 100%, well before this simple model's straight-line math suggests trouble.
- No queueing delay. This estimates raw throughput capacity, not how long a request waits in a queue before an instance is free — that wait grows sharply as utilization climbs, which is exactly why "near capacity" is flagged as a warning here rather than treated as identical to "comfortable."
- Uniform instances, uniform load. Real traffic isn't evenly distributed across instances, and a slow downstream dependency or a cold cache can make one instance's real latency look nothing like another's.
Treat the result as a back-of-envelope floor for capacity planning — genuinely useful for sizing a rough instance count before a load test, not a substitute for actually running one.
Try it yourself
Cache Hit Ratio Calculator and Database Index Cost Estimator cover two other numbers worth knowing before a system is under real load — how much of your read traffic a cache is actually absorbing, and whether an index's read savings are worth its write cost.
FAQ
Why does adding instances need to match latency exactly to hit a target?
Because Little's Law is an equality, not an approximation with slack built in — it holds for any stable queueing system regardless of the specifics of arrival patterns or service time distributions. If latency doubles and the instance count doesn't, the target throughput is mathematically no longer sustainable, full stop.
Why is 100% utilization flagged as a problem instead of "exactly enough"?
Because real traffic doesn't arrive in a perfectly smooth, evenly-spaced stream — it bursts. A system provisioned for exactly its average target load has zero headroom for the moment traffic exceeds that average even briefly, which is normal, not an edge case.
Is anything I enter here sent anywhere?
No — this calculation runs entirely in your browser. Nothing here is ever sent to a server.