Every incoming API request is drawn as a small cube travelling toward a gate. At the gate, a rate-limiting algorithm decides in real time whether the request is allowed through to the server or throttled. The glowing cylinder above the gate is the algorithm's live capacity gauge, and the strip chart below plots every accept/deny decision over the last few seconds.
Sliding window log rate limiters are the most accurate but the most memory-hungry, since they must remember every request timestamp inside the window — which is exactly why many production systems approximate them with a cheaper "sliding window counter" that blends two adjacent fixed windows instead.
Requests stream toward a gate where a token bucket, fixed window, or sliding window algorithm decides in real time whether to let each one through or throttle it — watch the live capacity gauge and strip chart change shape as you switch algorithms.
Each algorithm is run against the exact same incoming traffic. The token bucket refills and drains smoothly; the fixed window snaps to zero at each boundary; the sliding window log decays continuously — the differences you'd normally only see in a graph become a physical, moving gauge.
Pick an algorithm, set the incoming request rate and the limit/capacity, then tune the refill rate or window length. Fire a burst to see how each strategy absorbs a traffic spike, and toggle queuing to compare dropped versus retried requests.
Fixed window counters can let up to 2x their stated limit through in a short span if a burst straddles a window boundary — half the requests land in the tail of one window, half in the head of the next.