LimitLine / play the limiter
The quota is yours to spend. Watch how much is left, fire a request, follow it to the limiter, and find out why it came back a 200 or a 429 — in the selected algorithm's own numbers.
Tokens accrue continuously up to capacity. Spend a burst instantly, then move at the refill rate.
request you can still make
8.0 / 8 units · 7 per request
Bucket
ready now
Press Space to fire. Spam it — requests overlap, and each one is decided the moment it reaches the limiter.
Last verdict
Send a request. The verdict, the quota it spent, and the reason behind it land here.
Your requests
none yetNothing sent yet.
Request lifecycle
LimitLine expands a decision into the state reads, time math, mutations, and response signals that make it safe to operate.
Build a stable quota key from the smallest trustworthy identity: tenant, user, route, or a deliberate combination.
Use elapsed time or a window boundary to calculate the capacity available at the instant the request arrives.
Spend quota only when enough remains. Atomic execution keeps concurrent requests from spending the same unit twice.
Return the status, quota fields, and Retry-After signal a client can use to shape its next request.
Capacity 20 · refill 2 tokens/sec
The token model
No background job adds tokens. Each request calculates what elapsed time earned, clamps the result to capacity, and attempts to spend its cost in the same storage operation.
Choose the failure shape
Absorbs controlled bursts while a refill rate governs sustained traffic.
Uses minimal state, but two adjacent windows can admit a boundary spike.
Produces exact rolling-window decisions and pays with timestamp state per admitted request.
Shapes output at a fixed pace; useful when downstream work must remain uniform.
Production policy
A limiter remains trustworthy only when identity, topology, failure, and observability choices match the risk of the protected endpoint.
Expire idle identities and reject attacker-controlled key dimensions before they create unbounded state.
Public reads may preserve availability; login and payment endpoints usually choose stronger protection.
A nearby quota is fast. A global promise is stricter. Making both claims at once requires coordination.
Observe admissions, rejections, storage latency, failures, fairness, and key growth without logging raw identity.
local restored = math.min(capacity, tokens + elapsed * refill)
local allowed = restored >= cost
local remaining = allowed and (restored - cost) or restored
redis.call('HSET', key, 'tokens', remaining, 'updated_at', now)
redis.call('EXPIRE', key, ttl)
return { allowed and 1 or 0, remaining, retry_after }Redis guarantees atomic script and Function execution. LimitLine models those semantics; it does not connect to a hosted Redis instance. Redis documentation
HTTP/1.1 429 Too Many Requests
RateLimit-Policy: "default";q=12;w=3
RateLimit: "default";r=0;t=1
Retry-After: 1The consolidated RateLimit fields shown in the lab follow active IETF draft -11 and are labelled as work in progress. Read the draft
A good rate limiter is predictable to clients, cheap for the service, and boring for the people operating it.
Explore more systems