Rate limiting

Imagine an arcade with a separate capped credit tray for each player. A dispenser adds credit steadily, and an attendant spends the required credit before starting a game. Unspent credit can support a burst of plays, but a long absence cannot fill the tray beyond its rim. This is an authored structural analogy, not a description of commercial arcade hardware.

Arcade relationship	Limiter relationship
One labelled tray per player	One accounting state per budget key
A dispenser adds credit until the rim	Refill stops at bucket capacity
A game consumes its stated price	Admission debits request cost
A new dated coupon sheet each hour	A fixed window creates a new allowance
Dated used coupons remain for inspection	A rolling log retains individual timestamps
Attendants consult one tray	Workers share one budget

Breaks down when: paper coupons cannot provide Redis atomicity; physical dispensers need not refill continuously; people can transfer credits, but keys do not merge by themselves. Contrasting case: checking how many arcade seats are occupied measures current occupancy, not a player's spending rate. In real terms: a rate limit applies a chosen temporal allowance to a chosen identity; it does not prove that the service has spare capacity. S2

4.1 ExamHall: summary polling consumes export credit

EXH-1930 is a synthetic results-pipeline replay, not a production incident report. One tenant sends two summary reads followed by three export reads. Both routes have allowance two in this exercise. The first implementation keys by tenant; MR !2130 adds the route budget identifier. S2

ExamHall tenant accepted=2 rejected=3
ExamHall tenant+route accepted=4 rejected=1

The shared counter silently couples two workflows; adding the intended route scope separates their allowances (step 1). It does not increase either individual allowance. A policy that deliberately limits a tenant across all routes should retain the broader key. The observed difference demonstrates that the key is part of the product contract, not just a storage naming choice. S2

4.2 Payments ledger: expiring the left boundary

A ledger client sends three reads at virtual t=0 and three at t=10. With allowance three and a ten-second interval, both implementations admit the second batch: the fixed period has changed, and the rolling log removes timestamps exactly on its left boundary. That agreement is specific to this spacing. The code uses actual Redis sorted-set removal, not a sleep. S3

payments fixed=6 rolling=6

4.3 The local HTTP boundary

Three requests reach a loopback ledger route at one virtual instant. Its token policy has two initial credits. The real HTTP server forwards admissions and returns a quota response for the denied request. The script checks the response header; its suggested delay is calculated from the configured refill and never measured with a stopwatch. S2 S5

HTTP statuses=200,200,429 Retry-After-present=true

This run proves that the authored route emits its contract. Whether an HTTP field is required comes from the RFC, not from a server that was programmed to emit it. The fixture sends no production traffic and makes no claim about a client's eventual retry success. S2