Skip to content

PATTERN Cited by 1 source

De-prioritize all except target

Pattern

Prioritisation and de-prioritisation are duals. To prioritise one client identity without explicit exemption, set a high default rejection ratio globally, then lower the ratio (possibly to zero) only for the favoured identity.

"In another model, one could configure the throttler to reject a ratio of requests for all clients, and then have a lower, or zero rejection ratio for a particular client. Thus, a safe way to prioritize one client over others is to de-prioritize all other clients."

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

The duality

Two configurations produce the same effect:

Configuration A — per-client ratios

rejection_ratio[online-ddl-critical] = 0.0
rejection_ratio[etl-1]                = 0.9
rejection_ratio[etl-2]                = 0.9
rejection_ratio[etl-3]                = 0.9
...
rejection_ratio[etl-N]                = 0.9

Configuration B — global default + favoured override

rejection_ratio[default]             = 0.9
rejection_ratio[online-ddl-critical] = 0.0

Same outcome. The favoured client runs effectively unthrottled (subject only to the metric gate); everyone else is heavily backed off. The difference is operational footprint:

Configuration A Configuration B
Rule count N per non-favoured client 1 global + 1 favoured
New-client behaviour Full-speed until explicitly ratelimited Deprioritised by default
Configuration drift Easy to forget a client Default is explicit
Favoured-client discoverability Scattered One line

Configuration B wins in practice — name the favoured identity, suppress everyone else implicitly — which is why Noach names the pattern as an independent shape even though it is mathematically equivalent.

When each framing is natural

Use A when a small number of clients need distinct rejection rates and the rest should run at normal speed. Lets you tune the gradient.

Use B when one (or a few) identities need to run at full speed during a specific window and everyone else can tolerate being deprioritised. The wiki's canonical example is the incident-response scenario: one incident-fix job needs unthrottled access; everything else can wait.

Avoids exemption

Crucially, Configuration B does not exempt the favoured client from the system-health metric — it just sets that client's dice-roll rejection to zero. If the metric goes above threshold, every client is still rejected by the metric gate.

"It's important to highlight that both clients still play by the rules: none is given permission to act if the database has unhealthy metrics."

This is the essential difference from exemption: exemption ignores the metric; de-prioritisation-of-others respects it.

Worked example — incident response

Running incident: write-path issue; the fix is a one-off DML that must run. Steady-state workload is 10 ETL jobs + 3 reporting jobs + the normal online-DDL queue.

Configure:

rejection_ratio[default]                = 0.95
rejection_ratio[incident-fix-a4b2]       = 0.0
  • The incident fix checks → dice passes (ratio 0) → metric check passes if healthy → proceed.
  • Every other client: 95% dice rejection → back off → retry. The 5% that do consult metrics still block if the metric is above threshold.

The incident fix effectively monopolises throughput, but the throttler is still guarding the database.

When the incident resolves, drop the global ratio back (or let it expire under patterns/time-bounded-throttler-rule).

Compositions

Seen in

  • sources/2026-04-21-planetscale-anatomy-of-a-throttler-part-3 — canonical wiki introduction. Shlomi Noach names this as a separate configuration shape from the per-client ratio pattern, with the explicit "safe way to prioritize one client over others is to de-prioritize all other clients" framing.
Last updated · 319 distilled / 1,201 read