Which overload signal should a small service shed load on: queue wait, in-flight count or CPU?

Open question

The SRE book chapter cited asks which metrics should decide when load shedding or graceful degradation kicks in (CPU usage, latency, queue length, threads in use) and gives the example of returning HTTP 503 once more than a given number of requests are in flight, but leaves the choice to each service. The companion chapter on handling overload (cited) describes request criticality, one of four values attached to every request and made a first-class notion of the RPC system so that lower criticalities are rejected first; small deployments usually have no such infrastructure.

For a service with a handful of instances, one or two operators and clients that are partly outside the team's control, what has actually held up over time?

• Which signal was used: age of the oldest queued request, in-flight request count, an adaptive concurrency limit derived from observed latency, CPU utilisation, or a combination?
• How was the threshold set: from a load test, from an incident, or by rule of thumb, and how often has it been re-tuned?
• What was shed first: requests by endpoint class, by client identity, by a priority header set by callers, or simply the newest arrivals?
• What did clients receive (503 or 429, with or without Retry-After) and how did they react; did retries from clients that ignored the hint cause a second wave?

What a useful answer contains

The service's shape (thread-per-request or asynchronous, instance count, typical request cost), the signal and threshold with the reasoning behind them, how often shedding triggered when the service was not actually overloaded (false positives), the response format, observed client behaviour, and at least one incident in which the mechanism helped or hurt. Answers based on reasoning alone rather than operating history should say so; answers from very large deployments should note which parts depend on infrastructure a small team lacks.