Capacity from Little's law and the bottleneck

Each wash takes 40 minutes, and customers queue with their baskets.

In the launderette	In the system
eight washers at 40 minutes a wash: at most 12 loads an hour, however long the line	a stage's capacity (step 3)
a second door, more baskets or more folding tables change nothing	only the bottleneck counts (step 4)
loads in the shop, on average = loads finished an hour × hours each stays	L = λW (steps 1–2)
a Saturday with 36 loads in the shop: each stays 3 hours, 40 minutes of it washing	W = L ÷ X (step 6)
a customer whose parking ticket runs out before a washer frees goes home	a timeout (step 9)
a sign-up sheet bringing one customer back every 5 minutes: each visit lasts 40 minutes, and the day still ends at the same time	admitting at X (steps 9–10)
regulars who wash, go home for an hour and come back: each one's round is the hour plus the wash	a boundary that includes the pauses (step 11)

In real terms: find the stage with the fewest units per unit of work; its rate is the system's rate, and anything more in flight is a queue.

Breaks down when: washers never slow each other down. Postgres cores are shared by time-slicing, so extra concurrency slows every running query, not just the next in line.

Contrasting case: a launderette that is never busy. With no queue, W is just the wash time; Little's law still holds, but no stage is the limit yet.

4.1 ExamHall: the 09:00 start, re-executed

4.1 ECON-201 at 09:00: 2,400 candidates, 6 instances x pool 20, 2,000 ms acquire timeout; Postgres 8 cores, 20 ms CPU per paper query
4.1 bottleneck X = 8 cores ÷ 20 ms = 400 paper queries a second, fleet-wide
4.1 all at once: in Postgres 120 at a time · each query 300 ms · L = X × W = 400 × 0.3 = 120
4.1 all at once: served 840 · failed at the acquire timeout 1,560 · last served at 2,100 ms · longest pool wait of a served one 1,800 ms
4.1 admitted 8 every 20 ms (400 a second): served 2,400 · failed 0 · in Postgres at most 8 · each query 20 ms · last admitted at 5,980 ms · last served at 6,000 ms

The 300 ms is not slowness in Postgres: 120 queries share 8 cores, so W = 120 ÷ 400 (step 6). Admitting at X keeps every query at 20 ms and serves everyone by 6.0 s (steps 9–10).

4.2 ExamHall: "we doubled the instances" (EXH-1690, MR !1890)

At a practice sitting the API was doubled to 12 instances. Same model, with the timeout and without it:

4.2 change                         | conns | in Postgres | each query | served / failed (2 s timeout) | last served, no timeout
4.2 6 instances x pool 20 (today)  |   120 |         120 |     300 ms |   840 / 1,560                 | 6.0 s
4.2 6 instances x pool 50          |   300 |         300 |     750 ms |   900 / 1,500                 | 6.0 s
4.2 12 instances x pool 20         |   240 |         240 |     600 ms |   960 / 1,440                 | 6.0 s
4.2 400/s admission, 6 x 20        |   120 |           8 |      20 ms | 2,400 / 0                     | 6.0 s

Every row ends at 6.0 s: 2,400 ÷ 400 (step 9). More instances or connections only move the queue into Postgres and stretch each query. The model does not refuse connections above max_connections 150; that refusal is pooling's step 8. MR !1890 admits exam starts at 400 a second instead.

4.3 Proof domain, catalog: Little's law on random traffic

A catalog's image-resize service with 3 workers, one simulated hour, two very different traffic shapes from one seeded generator:

4.3 random (exponential) gaps and resize times: 14,772 images · λ 4.102/s · W 1.405 s · λW 5.762 · L measured 5.762
4.3 near-regular (uniform ±50%) gaps and resize times: 14,513 images · λ 4.031/s · W 0.637 s · λW 2.567 · L measured 2.567

Burstier traffic waits longer, yet L = λW holds exactly for both (steps 1–2).