Skip to content

CONCEPT Cited by 1 source

Throttler exemption

Definition

Throttler exemption is the design choice to let specific clients — identified by client identity — bypass all or some of the throttler's checks, regardless of the system-health metric state. Exempted requests proceed as if the throttler is disabled for them.

Exemption's appeal is operational simplicity: a single flag per client identity makes essential traffic unblockable. Its cost is structural: it creates client starvation for every non-exempt client whenever the exempted client pushes the metric above threshold.

Why exemption is risky

"Exemption is risky because it not only blocks operation of other players but can also degrade system performance, going against the very reason for the throttler's existence."

— Shlomi Noach, Source: sources/2026-04-21-planetscale-anatomy-of-a-throttler-part-3

Two compounding harms:

  1. Starvation of other clients. The exempted client's unthrottled load pins the metric above threshold; the throttler continuously rejects everyone else. Worked example: replication lag pinned at minutes for hours; every other client gets zero progress throughout.
  2. Degraded database health. The throttler exists precisely because unbounded workloads damage the database. An exempted client — by design — gets to do exactly the damage the throttler was installed to prevent.

The throttler's raison d'être is making bad load-shapes impossible. An exemption is a hole punched through that guarantee.

When exemption is justified

Noach names three cases where exemption is acceptable despite the risks:

1. Short transient starvation

"Nothing lasts forever. If a client is starved for 10 minutes out of a total runtime of 12 hours, this may not be a big deal."

Bounded, measured, accepted as part of the workload's economics. Works when the starvation share is small relative to the victim's total runtime.

2. Incident-response fixes

"If a task absolutely has to run at all costs (e.g., fixing an incident) and that pushes resources beyond what we want to see in normal times, so be it."

The incident fix is more valuable than steady-state fairness. The exemption is a deliberate, conscious choice with a clear outcome criterion (incident resolved → exemption removed).

3. Essential system components

"If the client is an essential part of the system itself, and goes through the throttling mechanism due to data flow design, and does not handle massive data changes, then we may and should exempt it altogether."

An in-system component that passes through the throttler for structural reasons (e.g. because it shares a client library) but has minuscule resource impact. Exempting it removes unnecessary overhead without meaningful starvation risk.

Exemption in disguise

Two mechanisms that look like fine-grained control but are functionally exemption:

Per-client differential metrics

"While the second client throttles based on replication lag and also on load average, the first client is effectively exempted from checking load average."

When one client consults fewer metrics than another, it is exempt from those unchecked metrics. If the first client's workload spikes one of those metrics, the second client gets starved on it.

Unidentified rogue clients

A client that simply doesn't consult the throttler is exempt-by-omission. The cooperative-model structural hole.

Preferred alternatives

For anything other than the three justified cases, prefer ratio-based prioritisation over exemption:

Seen in

  • sources/2026-04-21-planetscale-anatomy-of-a-throttler-part-3 — canonical wiki introduction. Shlomi Noach opens with exemption as the naive answer to prioritisation, walks the starvation failure mode, then introduces probabilistic rejection as the safer alternative while keeping the three justified exemption cases explicitly open.
Last updated · 319 distilled / 1,201 read