Availability depends on the work accepted before rejection

A byte-rate graph cannot reveal every availability bottleneck. A small handshake attempt can consume CPU; a partial request can retain memory; an authenticated request can trigger expensive downstream fan-out. For CPU, multiply accepted request rate by CPU-seconds per request and compare the result with available CPU-seconds per wall-clock second. For memory, count retained objects and their actual size and lifetime. Keep legitimate and rejected work in the accounting, since a fast error path is still a path with cost.

Resource asymmetry does not require a large response packet. Parsing complexity, verification, cache misses, and dependency calls can amplify small inputs into substantial internal work. Conversely, a cheap precheck can sometimes avoid a more expensive stage, provided the precheck itself has bounded cost and does not become an unchecked state allocation. Measure stages separately under an explicitly authorized synthetic workload. The examples here are capacity arithmetic, not instructions for generating harmful traffic against someone else's service.

A rate limit bounds admissions over a stated time policy; a concurrency limit bounds simultaneous in-flight work. They answer different questions when request durations vary. An unbounded queue can convert a short overload into long tail latency and memory pressure. A finite queue, deadlines, cancellation, and load shedding can limit retained work, but each needs a defined response and retry policy. Retrying denied work immediately can increase offered load and make a local protective action worsen the wider system.

Identity-based quotas can separate customers better than a single source-IP bucket when many legitimate clients share a NAT, but verified identity may be unavailable before an expensive handshake or authentication stage. Use layered limits appropriate to what is known at each boundary. Also bound log volume and dependency fan-out on rejected requests. A rejection counter rising while CPU and downstream traffic continue to scale unchecked is evidence that the intended cost boundary has not yet been achieved.

A protective mechanism succeeds only relative to an availability objective. Track successful legitimate throughput, latency, fairness, rejected work cost, resource saturation, and recovery after the synthetic load ends. Use bounded tests and explicit stop conditions in an environment authorized for the experiment. A system that returns many errors quickly may still starve legitimate requests sharing a worker pool. Inspect whether admission checks, cryptographic workers, and application work share the same exhausted resource.

The queue lab provides a small fixed-rate comparison. Reset, set both λ=4 and μ=3, predict that the four initial work items grow by one per second, then Play or Step. Reset again, set both λ=2 and μ=3, and predict drainage to zero at four seconds before playing. These are separate runs: parameter edits retain elapsed time and recompute from the initial four. The fluid model has no attacker, finite buffer, CPU scheduler, or admission limiter, and its M/M/1 readout requires additional stochastic assumptions not established by this exercise.