Priority Queueing
Classifying requests by business importance so that overload sheds the least valuable work first rather than an arbitrary slice.
Uniform shedding is better than collapse and considerably worse than shedding deliberately. If 20% of traffic must be dropped, dropping 20% of checkouts is a very different business outcome from dropping 20% of recommendation panels.
Making it work requires three things that are easy to skip:
A classification that arrives with the request. A priority assigned at the edge — derived from endpoint, customer tier, or whether the call is user-facing or batch — and propagated through every hop, or downstream services cannot honour it.
An agreed order, signed off by the business. Engineering should not be deciding during an incident that marketing personalisation is less important than search. Agree the tiers in advance.
Protection against starvation. A strict priority order can starve low-priority work indefinitely; weighted fair queueing or a reserved minimum share avoids a background job never running again.
The related pattern is criticality-aware retries: low-priority requests should not retry during overload at all, since their retries consume capacity that high-priority work needs.