Admission Control for Load Shedding

Admission control decides whether new work should enter a system based on available capacity, priority, and current conditions. It is a proactive form of load shedding: instead of accepting work that the system cannot safely process, it rejects, delays, or redirects selected requests.

Admission control sits at the boundary of a service and makes an accept-or-reject decision before expensive processing begins. The decision can consider concurrency, queue depth, CPU or memory pressure, downstream capacity, request priority, deadlines, and tenant quotas.

A key goal is to protect system stability under overload. If incoming work exceeds processing capacity, allowing every request into an unbounded queue can increase latency, consume memory, and eventually cause cascading failures. Admission control limits the amount or type of work entering the system so that accepted requests retain useful service quality.

Load shedding is the broader technique of deliberately discarding or refusing work when demand exceeds what the system can handle. Admission control is one way to implement it, usually before the work consumes substantial resources. Rejection can be explicit, such as HTTP `429 Too Many Requests` or `503 Service Unavailable`, or requests can be routed to another capacity pool when the architecture supports that.

Senior engineers should distinguish admission control from rate limiting and concurrency limiting. A rate limiter constrains how frequently requests may arrive during a time window, while a concurrency limit constrains how many operations are active simultaneously. Admission control can use either mechanism as an input and can additionally make decisions based on priority, resource forecasts, dependencies, or system health.

A robust design also defines what happens to rejected work. High-priority requests may receive preferential admission, while low-priority or best-effort work is shed first. The system should avoid retry storms by communicating appropriate retry behavior and by making rejection inexpensive and observable.

Key points

• Protects finite capacity by deciding whether work may enter the system.
• Uses current load, capacity, priority, quotas, and dependency health to make admission decisions.
• Load shedding rejects or discards work when demand exceeds safe processing capacity.
• Rate limiting controls arrival frequency; concurrency limiting controls active work; admission control can incorporate both.
• Overload responses should be cheap, observable, and designed to avoid retry amplification.

Interview questions

What is admission control, and why is it useful during overload?

Admission control determines whether a new unit of work should be accepted based on the system's ability to process it safely. During overload, accepting everything can increase queues, latency, and resource consumption. Rejecting selected work preserves capacity for requests that the system can still serve effectively. The decision can be based on concurrency, queue depth, priority, quotas, or resource health.

How does admission control differ from rate limiting?

Rate limiting generally constrains request arrival over a defined period, such as requests per second or requests per minute. Admission control asks whether a particular unit of work should enter the system given current conditions. It can incorporate rate limits but can also consider active concurrency, queue depth, request priority, deadlines, and downstream health. Therefore, admission control is a broader decision mechanism than a simple request-rate constraint.

How would you design admission control for a Java backend under heavy traffic?

I would first identify the scarce resources and define safe operating limits, such as maximum active requests, queue depth, and downstream concurrency. The admission decision could combine those signals with request priority, tenant quotas, and dependency health. I would make rejection cheap, return an appropriate overload response, and prevent clients from creating retry amplification. Finally, I would instrument accepted and rejected traffic, saturation, latency, and queue behavior so the policy can be tuned from production evidence.

How can admission control help prevent cascading failure?

Without admission control, overload at one component can increase queues and resource usage until that component becomes slower or fails. The resulting retries and blocked resources can then overload other services, producing a cascade. Admission control limits work before scarce resources are consumed and can also account for unhealthy dependencies. Preserving capacity for critical traffic reduces the amount of overload propagated through the dependency graph.

How would you handle priority in an admission-control policy?

I would define explicit traffic classes rather than relying on incidental request ordering. Critical work could receive a reserved capacity budget, while best-effort work could be rejected earlier as saturation increases. The policy should still enforce per-tenant or per-class limits so one source cannot monopolize shared capacity. I would validate the policy with load tests and production metrics to ensure priority behavior matches the intended service objectives.