Overload protection

Climbers need equipment checks before entering the roped floor. An uncontrolled inspection backlog can crowd the area while people miss their booked session. The marshal admits only the people the inspection area can handle, asks others to wait outside, and turns away arrivals whose session cannot be reached. Moving the queue outside does not extend anyone's booking.

Climbing gym	Service mechanism
Equipment inspection area	Expensive backend work
Limit on people inside	Admission bound
Waiting outside the roped floor	External waiting room
Missed booked session	Result beyond its useful deadline

In real terms: keep a backlog from spending the capacity intended for useful work. Breaks down when: people can negotiate another booking; a request deadline must not silently restart. Contrasting case: a quiet gym may enforce a member's daily entry allowance even without crowding. Likewise, a client quota and an overload signal answer different questions. S5

The waiting area also needs a policy for expiry and excess demand. It is not an unlimited storage promise. A rejection still consumes some networking and application resources; protection has a finite operating range. Selecting a bound requires testing the actual service, because request costs can differ. This lesson's identical-cost jobs isolate admission decisions; they do not predict a production safe limit. S6

4.1 ExamHall: expired refreshes block useful work

EXH-1640, Expired proctor refreshes occupy the service queue. A local HTTP backend uses one virtual worker. Each job consumes one tick; deadlines are absolute and inclusive. The fixture intentionally finishes expired work instead of cancelling it. Actual HTTP requests remain open until their modelled completion; explicit arrival acknowledgements remove races. S2

The low-load run receives two requests at tick zero with deadline two, then two at tick two with deadline four. The overload run receives eight in the first wave and the same later wave. Count useful completions through tick four, including completions at that tick. Both runs have the same worker and observation window.

example useful completions: low=4 unbounded=2 bounded=4

Expired first-wave jobs occupy later worker turns in the unbounded run. This is a collapse in useful completions, even though service continues. It demonstrates wasted FIFO work, not a measurement of CPU thrashing. MR !1840, Bound proctor admission before expensive refresh work, limits total inside to two. Excess arrivals receive early errors; capacity is available when the later wave arrives. S1

4.2 Catalog: waiting does not restart a deadline

A catalog gateway initially holds three requests outside a backend that permits two inside. Every request has the original absolute deadline one. The gateway admits another only after capacity frees and discards waiting entries whose deadlines have passed. Through tick three, only one result is useful. A request admitted exactly at its deadline cannot finish a one-tick job in time; preserving the deadline exposes that lost opportunity.

waiting room admission layout: inside=2 outside=3; absolute-deadline useful=1

The HTTP transport is real; the waiting-room controller and service-cost scheduler are deliberately small executed models. No virtual tick represents measured wall-clock latency. A real waiting room protects the origin by withholding arrivals; its user experience and admission policy require separate design. S3