Little's Law

In practice

Rearranged, it answers the three questions that come up in every capacity conversation:

• How much concurrency do I need? L = λ × W. 2,000 req/s at 50 ms → 100 requests in flight. That is your minimum thread or connection count.
• What throughput can I get? λ = L / W. A pool of 50 connections at 20 ms per query → 2,500 queries/s, and not one more.
• What latency should I expect? W = L / λ. A queue holding 500 items draining at 100/s → 5 seconds of wait, before service time.

Worked example: a worker pool of 20 threads processing jobs that take 300 ms sustains 20 / 0.3 = 66 jobs/s. If the queue receives 100/s, it is not "a bit behind" — it is diverging, and the backlog grows by 34 jobs every second until something breaks. No amount of tuning fixes an arrival rate above the service rate; only more capacity or backpressure does.

When it matters

Sizing thread pools, connection pools and consumer counts; deciding whether a queue backlog will drain; reading a load test.

Common mistake

Applying it to an unstable system. Little's Law assumes λ < service capacity. Once the queue is growing without bound, W is not a constant to plug in — it is climbing, and the law is telling you that, not giving you a number.