This is a provider-neutral token-bucket illustration, not a running rate limiter.
Policy: start with 3 tokens, refill 1 token at each whole-second tick, cap at 3,
charge 1 token per admitted attempt, and do not queue rejected requests.
All zero-second frames describe ordering within one burst before the first refill.
The admitted lane is a history of admission decisions, not concurrent execution.
The tokens drawn beside admitted requests are spent-token bookkeeping, not permits
returned on completion. HTTP 429 and Retry-After are explicit example choices.
Stable data-morph names identify the same requests and tokens on successive pages.
There is no custom JavaScript, timer, or in-slide CSS animation in this deck.
Sources: https://learn.microsoft.com/aspnet/core/performance/rate-limit#token-bucket-limiter
https://www.rfc-editor.org/rfc/rfc6585.html#section-4
Advancing one slide moves request A and token 1 through Marp's native morph.
The token is spent at admission; this frame makes no claim about whether A's
handler has started or finished. B, C, and D still await their admission decision
within the same illustrated burst, not in a configured server-side waiting queue.
Two admission decisions are grouped into this keyframe so B/C and their tokens
morph together. Each admission still costs one token. This is not a claim that
the limiter performs one atomic two-request operation.
Token bucket permits an initial burst from saved capacity; its refill rate is
not the same as a fixed-window maximum of one request in every second.
RFC 6585 defines HTTP 429 for rate limiting and permits a Retry-After header.
This example chooses a one-second delay because the next refill is at t=1.
A real application must configure its response and calculate meaningful retry
metadata; other implementations may queue, return a different status, or drop.
Nothing about a Retry-After header guarantees success: another request may spend
the newly available token first. D was rejected, not retained for later execution.
At t=1 exactly one periodic refill has occurred. Token 4 is new; tokens 1-3 stay
in spent history so the visual does not imply they were returned by completed work.
D2 is a new client attempt after waiting, not D being dequeued by the server.
Other arrivals and timer jitter are omitted. A real retry may still be rejected.
Concurrency limiters replenish permits on completion; token buckets replenish
over time. That is the distinction this frame is meant to make visible.
This keyframe shows the favorable retry outcome for a quiet system. The client
waited for the next refill and then submitted a new request. The admission check
is performed again; the prior rejection does not reserve a future token.
No claim is made that every real retry succeeds or that 429 handling is universal.
After the retry at t=1 the balance is zero. Ticks at t=2, 3, and 4 add tokens
5, 6, and 7. The t=5 refill cannot take the balance above 3 and is discarded.
The admitted-history lane remains unchanged: elapsed time is not evidence that
those requests have completed, and completion is not what replenishes the bucket.
This deck has only complete authored snapshots. Going backward rewinds the
explanation, not a real service. PDF/no-JS output contains all seven states.
The animation method uses stable view-transition-name values, one unique name per
object per slide. Marp supplies all transitions; no custom runtime is included.