FA-73672 / Rate limiter algorithms / Member archive

Priority limiter with reserved high-priority capacity: low traffic ignores total usage · case 02

When high traffic is heavy, low requests are still admitted and the window exceeds capacity.

Member previewVariant 2 · 3 implementations · 7 checks per implementation

Case contract

Input {capacity, reserved_high, requests [[t_ms, priority]]} with nondecreasing t, one-second epoch windows. Only the exact label "high" is high priority; every other label is low. A high request is admitted while total admitted < capacity. A low request is admitted only while admitted low < capacity - reserved_high and total < capacity. Both counters reset each window. Return [decisions, [low, high] of the final window].

Why this case matters

Shared limiters reserve headroom for critical traffic (health checks, payments) so that bulk clients cannot starve it; the reserve arithmetic decides whether the guarantee holds.

One recorded failure

Sample boundary fixture

This sample comes from the broken implementation of a controlled reproducer.

Boundary fixture	Actual	Expected	Outcome
high traffic blocks low at capacity	`[["allow", "allow", "allow", "allow", "allow", "allow"], [3, 3]]`	`[["allow", "allow", "allow", "allow", "deny", "deny"], [1, 3]]`	Failed

MEMBER ARCHIVE

The complete case is available to members.

This record includes three runnable implementations, regression fixtures, execution results, and source hashes.

Member access is invitation-based. Sign in with your invited account to inspect the sources.