Little's Law Calculator
Little's Law ties the three numbers every capacity plan rests on: the average number of in-flight requests, the throughput, and the latency. Solve for whichever you don't know — size a connection pool from QPS and latency, back out the latency a queue depth implies, or find the throughput a fixed worker count can sustain. Includes a utilisation read-out so you can see when you're driving the system into the danger zone.
Hot. Past ~80% utilisation, small bursts cause large queue spikes. Keep steady-state headroom for variance.
L = λ × W holds for the long-run average of any stable system. It sizes for the mean — add headroom for the tail (p99 spikes, bursts) it deliberately ignores.
Three numbers describe every busy system, and one tiny law ties them together. How many requests are in flight right now (L), how fast they arrive (λ), and how long each one takes (W). Little's Law says you never get to pick all three independently: L = λ × W.
That equation is the most reused back-of-envelope in system design. Sizing a connection pool? The number of connections you need is just throughput times latency: 500 requests per second at 40 ms each means 20 in flight, so 20 is your floor. Wondering what latency a queue of 50 in-flight jobs implies at 200 jobs/sec? Rearrange to W = L ÷ λ = 250 ms. Every capacity question is one of these three unknowns.
The trap is utilisation. If you have 24 workers and Little's Law says you need 20 in flight, you are at ρ = 0.83 — and queueing theory is unkind near ρ = 1: latency rises non-linearly as you approach full utilisation, so a small traffic burst produces a big queue. That is why the law is a starting point, not a finish line: size for the average with it, then leave headroom for the variance it deliberately ignores.
How it works
- L = λ × W: concurrency = throughput × latency.
- In-flight count L is your minimum pool / worker size.
- Utilisation ρ = L ÷ servers — keep it below ~0.8.
- Exact for long-run averages of a stable system.
Frequently asked questions
What is Little's Law?
Little's Law says that, for any stable system, the average number of items inside it (L) equals the average arrival rate (λ) times the average time each item spends inside (W): L = λW. It holds regardless of arrival distribution, service order or number of servers — which is why it underpins so much capacity planning. If 500 requests/sec each take 40 ms, there are on average 500 × 0.04 = 20 requests in flight at any instant.
How do I use it to size a connection pool or worker count?
The in-flight count L is exactly how many concurrent slots you need. Take your peak throughput and your typical latency, multiply, and round up with headroom — that is your minimum pool or worker count. Undersize it and requests queue for a slot, inflating latency; oversize it and you waste memory and may overwhelm a downstream. This is the single most useful back-of-envelope in system design.
What does utilisation tell me?
If you also give a server/worker count, the tool computes utilisation ρ = L ÷ servers — the fraction of your concurrency budget in use. Queueing theory warns that latency climbs sharply as ρ approaches 1: past roughly 70–80% utilisation, small bursts cause large queue spikes. Keep steady-state ρ comfortably below 1 and reserve the gap for traffic variance.
What are the assumptions and limits?
Little's Law is exact for long-run averages of a stable system (arrivals ≈ departures). It says nothing about the distribution — a p99 latency spike or a burst can blow past the average concurrency even when the mean holds. Use it to size for the average and then add headroom for variance; pair it with a percentile view for tail behaviour.