the request budget that arrived after the surface

The platform shipped its public surfaces before it shipped a limit on how often they could be asked. That is the ordinary order of events, and the review said so plainly: no request budget at all on the server facing the public. The fix extended an existing in-memory limiter from the single scope it had been written for to the two that mattered, and gave each scope its own allowance instead of one global number.

The allowances were chosen against a use case rather than a round figure. The public budget's burst had to be large enough that one heavy page load — a shell, its assets, its data calls — sat inside a single burst, because a limiter that breaks an ordinary visitor is a limiter that gets switched off. The staff surface got a tighter budget, since its traffic is a handful of people doing deliberate actions. The authentication scope kept its own, unchanged.

The engineering detail worth noticing is the clock. The limiter takes an injectable clock, so refill, burst capping, per-caller isolation and stale-bucket cleanup are tested deterministically, with no sleeps and no global state leaking between tests. Six tests, one of them an integration test asserting that a request past the burst is refused rather than quietly served.

What was not solved is recorded as unsolved: allowances per venue and per API key are a later item, and the counters live in one process, so the effective budget is per instance rather than per system, and grows with the instance count. What it proves is a preference — the team reached for the limit it could test, then described its shape honestly instead of claiming a guarantee it did not have.