pattern

Admission Control

Deciding at the edge whether to accept a request at all, based on current capacity, before any work is done on it.

overloadsheddingcapacity

Load shedding is often implemented deep in the stack, after a request has already consumed a connection, a thread, an authentication check and a database lookup. Admission control moves the decision to the front, where rejecting costs almost nothing.

The decision input matters more than the mechanism. Queue depth or in-flight concurrency is a good signal because it rises before latency does. CPU is a poor one, because a service can be latency-bound while CPU is idle. Measured latency against a target works well and is the basis of adaptive schemes such as controllers modelled on TCP Vegas, which infer capacity from latency gradient rather than requiring a configured limit.

The refinement that makes it fair: admission decisions should consider who is asking. Under overload, shedding uniformly punishes the well-behaved caller as much as the runaway one. Per-tenant or per-client concurrency limits mean a single misbehaving consumer is throttled while everyone else is unaffected — which is the same insight as shuffle sharding, applied to admission rather than placement.