← Back to Labs

API Rate Limiting Lab

Run the same request burst through fixed windows, sliding control, token buckets, and a shared edge counter.

Traffic profileChoose the caller shape before stepping the limiter
Identity key in this scenario
apiKey=frankfurt-batch-1 · route=/search
The caller arrives just before reset after already spending the previous window heavily.
Client burst8 requests queuedapiKey=frankfurt-batch-1 · route=/searchEdge counterlimit 6 / 60sidentity chosen before budget checkAlgorithm statesliding est 4/6refill 2 req/s when bucket mode appliesShared verdictallow pathallow 8 · block 0Retry-After 1s when blockedreqWrong identity means wrong fairness, even if the math is perfect.
Burst outcome in this step
allowallowallowallowallowallowallowallow
Counter snapshots
current window used: 0/6
previous window used: 5/6
sliding estimate: 4/6
Token bucket
capacity: 8
starting tokens: 3
tokens left after burst: 0
Step 1 / 6Pick the right identity key before you count anything

A limiter starts by deciding who is consuming the budget. IP alone is rarely enough for a real API.

Arrow keys to navigate · R to reset

Tap dots to jump to any step

Read the full article →Take the quiz →