# Little's law

> Work in progress equals throughput times latency — the formula behind pool, queue and fleet sizes.

Concept · Requirements & scale · https://levelcode.org/concepts/littles-law

Little's law relates three quantities in any stable system where things arrive, wait or work, and leave:

```text
L = λ × W
items in the system = arrival rate × average time each item spends in the system
```

It holds for requests in a server, connections in a pool, messages in a queue, or people in a coffee shop, regardless of how arrivals are distributed.

## Using it

**Concurrency from throughput.** 8,000 requests/s at 25 ms average means 8,000 × 0.025 = **200 requests in flight**. If each instance handles 50 concurrent requests well, you need 4 instances — plan for 6–8 to keep headroom.

**Pool sizes.** 3,000 queries/s at 4 ms each keeps 3,000 × 0.004 = **12 connections busy** on average. A pool of 20–30 handles bursts; a pool of 500 only adds load on the database.

**Queue delay.** A queue holds 60,000 messages and consumers process 2,000/s, so a new message waits about W = L / λ = **30 seconds**.

## Why it explains outages

Rearranged, `W = L / λ`: when a dependency slows down (W rises) and arrivals don't change, L — the number of requests held open — rises in proportion. A dependency going from 50 ms to 5 s means 100 times as many requests in flight, which is how one slow service exhausts its callers' threads, connections and memory. That's why every call needs a [timeout](https://levelcode.org/concepts/timeouts), and why [bulkheads](https://levelcode.org/concepts/bulkheads) cap concurrency per dependency.

The law describes averages in a steady state. During a burst, or when arrival rate exceeds capacity, queues grow without bound until something sheds load ([backpressure](https://levelcode.org/concepts/backpressure)).