Systems & Backend

Load Shedding

Deliberately dropping or rejecting some requests under overload, to protect a system’s ability to serve the rest.

When incoming demand exceeds what a system can handle, trying to serve every request anyway usually means the system slows down for everyone until it collapses entirely. Load shedding instead deliberately rejects a portion of requests — cheaply and fast, often the least important ones by some priority rule — so the remaining capacity can keep serving the rest with healthy latency, rather than every request degrading together.

Worked example: under overload, deliberately reject a fraction of requests early (return 503 fast) so the ones you accept complete, instead of accepting everything and collapsing into timeouts where nobody is served. Gotcha: shed the RIGHT requests — drop low-priority/cheap-to-reject work first, protect health checks and critical paths — and shed at the edge before expensive work runs; shedding after the DB query already ran wastes the capacity you were protecting.