Little's Law: The One Equation Every Engineer Should Know
A result from queueing theory that links load, latency and concurrency — and quietly explains most capacity problems.
Little's Law is a result from queueing theory, a branch of applied mathematics, and it fits in one line: L = λ × W. The average number of items in a system (L) equals the average rate at which they arrive (λ) multiplied by the average time each one spends inside (W). The system can be a checkout line, a thread pool, a message queue or a whole microservice. The law does not care.
Take an API that receives 200 requests per second, each taking 250 milliseconds on average. L = 200 × 0.25 = 50, so about 50 requests are in flight at any moment. That number is your real concurrency. It tells you how many threads, connections or workers you need to keep up, with no load test required.
The law is most useful when something goes wrong. Suppose a slow downstream dependency pushes latency from 250 ms to 1 second while traffic stays at 200 requests per second. In-flight work jumps from 50 to 200. If your pool holds 100 workers, the other 100 requests wait in a queue, which makes each request slower, which raises L again. That feedback loop is how a modest slowdown becomes an outage. The arithmetic was visible before the incident.
Little's Law is also remarkable for what it does not assume. It holds for any arrival pattern and any service-time distribution, as long as the system is stable over the long run. That generality is why it appears everywhere: in manufacturing as work-in-progress, in project management as cycle time, and in capacity planning as concurrency.
Used in reverse, it gives you a measurement trick. If you can count items in flight and know the throughput, you can compute average latency without timing anything. If you cut work-in-progress, as Kanban teams do, average cycle time falls at the same throughput. Whenever someone says a system needs more capacity, ask what L, λ and W are today, and which one you can actually change.