Does Little's Law require Poisson arrivals or FIFO queues?

No. That is a common misunderstanding from queueing examples that start with nicer mathematical assumptions. Little's Law does not require Poisson traffic, smooth arrivals, FIFO ordering, or any particular scheduling policy. Bursts, priority queues, batches, and round-robin service still satisfy it when measured over a stable interval and a consistent boundary.

Which rate should I use for lambda?

Use the rate that crosses the boundary you are analysing. If rejected, timed-out, or rate-limited work never enters an internal queue, do not count it for that queue. In a stable system, admitted arrivals and completions should be close over the measurement window, so either can be used if the boundary is clear.

Why does Little's Law fail during incidents?

It usually has not failed; the stability assumption has. If arrivals exceed departures for the whole window, backlog is changing rather than fluctuating around a steady level. You can still use the relationship on stable subperiods or with care around changing inventory, but the simple steady-state form is not the right diagnostic.

Can Little's Law tell me how many replicas or workers to run?

It can sanity-check the implied concurrency, but it does not choose a safe capacity by itself. The answer depends on service-time distribution, tail latency goals, resource contention, retries, and headroom. It tells you the average amount of work that must be in progress for a given throughput and average time.

Little's Law

Little's Law is the queueing relationship L = lambda x W: average in-flight work equals average throughput multiplied by average time in the system. It applies to any stable system boundary, regardless of arrival pattern or service order, as long as the rate and time are measured over the same boundary.

Little's Law is needed because production systems often make latency, backlog, and capacity look like separate mysteries. A growing queue may be read as a slow worker problem, a scaling problem, or a traffic problem. The law gives one invariant that connects them: if work arrives or completes at some average rate and each item spends some average time inside the boundary, the average number present follows.

Mechanically, picture every request as drawing a horizontal line on a timeline from arrival to departure. The total area covered by those lines is both accumulated time spent by requests and accumulated occupancy of the system. Dividing that same area by elapsed time gives average in-flight work, while dividing by completed items gives average time per item. Rearranging gives L = lambda x W.

The main trade-off is that the law is simple because it is about averages, not tails or individual requests. It will not tell you whether latency is caused by CPU, locks, downstream calls, or retries. It also depends on a stable interval: if backlog is steadily accumulating or work is being dropped, using offered traffic instead of admitted or completed work gives a misleading answer.

Engineers meet Little's Law when checking autoscaling, queue depth, connection pools, worker counts, and concurrency limits. For a queue alone, L is queue depth and W is waiting time. For queue plus service, L is total in-flight work and W is end-to-end time inside that boundary. A common mistake is mixing these boundaries, such as comparing a broker backlog with HTTP latency.

Go deeper

DeploymentLittle's LawState L = lambda x W and apply it to a queue, knowing it holds for any arrival pattern and any service order.Open the lesson

Common questions

Does Little's Law require Poisson arrivals or FIFO queues?: No. That is a common misunderstanding from queueing examples that start with nicer mathematical assumptions. Little's Law does not require Poisson traffic, smooth arrivals, FIFO ordering, or any particular scheduling policy. Bursts, priority queues, batches, and round-robin service still satisfy it when measured over a stable interval and a consistent boundary.
Which rate should I use for lambda?: Use the rate that crosses the boundary you are analysing. If rejected, timed-out, or rate-limited work never enters an internal queue, do not count it for that queue. In a stable system, admitted arrivals and completions should be close over the measurement window, so either can be used if the boundary is clear.
Why does Little's Law fail during incidents?: It usually has not failed; the stability assumption has. If arrivals exceed departures for the whole window, backlog is changing rather than fluctuating around a steady level. You can still use the relationship on stable subperiods or with care around changing inventory, but the simple steady-state form is not the right diagnostic.
Can Little's Law tell me how many replicas or workers to run?: It can sanity-check the implied concurrency, but it does not choose a safe capacity by itself. The answer depends on service-time distribution, tail latency goals, resource contention, retries, and headroom. It tells you the average amount of work that must be in progress for a given throughput and average time.

Every term