Load shedding is the practice of dropping or rejecting a portion of incoming work when a system is overloaded. It protects the requests that are accepted by keeping queues short and response times acceptable.
Why it matters
A server that tries to process everything under overload usually fails for everyone: queues grow, latency climbs past client timeouts, and the work done is wasted because the caller already gave up. Rejecting 20 percent of traffic quickly can keep the other 80 percent healthy. Failing fast is also cheaper than failing slowly.
Example
A service decides based on queue depth or in-flight requests:
if in_flight > 200:
return 503 with header "Retry-After: 5"More refined strategies shed the least important work first: background jobs and bulk exports before logged-in checkouts, or anonymous bots before real customers. Health checks must stay cheap and exempt, otherwise the load balancer marks the shedding server unhealthy and sends its traffic to the others, spreading the overload.
Common mistakes
- Shedding with no signal to the client, so it retries immediately. Send Retry-After and use backoff.
- Treating all requests equally.
- Never testing it, so the first real use is an incident.
- Confusing it with rate limiting, which caps individual clients rather than protecting the server's total capacity.
Related
Get notified when this term updates
Plus occasional practical tips on uptime and monitoring, nothing else. Unsubscribe anytime.
यह पेज सामान्य जानकारी है, जिसे हमारी संपादकीय टीम ने लिखा है और दस्तावेज़ीकरण बदलने पर अपडेट किया जाता है। सर्वर और प्रदाता अलग-अलग होते हैं, इसलिए बदलाव पहले सुरक्षित तरीके से जाँचें। देखें: संपादकीय नीति और अस्वीकरण.