Calculate optimal API rate limiting with token bucket and sliding window algorithms visualization.
This tool models two common rate-limiting algorithms, token bucket and sliding window, against a traffic pattern you define: request rate, burst size, bucket capacity and refill rate, or window length and limit. It simulates the timeline and shows which requests pass immediately, which wait, and which get rejected, along with a chart of token level or window occupancy over time. The detail people most often miss: a large bucket capacity only buys a temporary burst allowance. If your sustained request rate exceeds the refill rate, throttling is inevitable no matter how big the bucket is - capacity just delays the first rejection.
A concrete input and expected output from the current implementation.
Input
Token bucket: capacity = 100 tokens, refill rate = 10 tokens/sec, incoming traffic = 15 requests/sec sustained
Expected output
Net drain rate is 5 tokens/sec (15 consumed minus 10 refilled). Starting full, the bucket empties after 100 / 5 = 20 seconds. After that point, throughput is capped at the refill rate: 10 requests/sec pass, 5 requests/sec are throttled, indefinitely.
Net drain is demand minus refill (15-10=5/sec); time to empty a full bucket is capacity divided by net drain (100/5=20s); once empty, allowed throughput can never exceed the refill rate.
You set a bucket capacity and a refill rate in tokens per second. The bucket starts full and gains tokens continuously up to capacity. Each request in your specified traffic pattern consumes one token if one is available; otherwise it's marked delayed or rejected. A chart plots token level over time so you can see exactly when the bucket empties and a burst starts getting throttled.
In sliding window mode you set a window length, e.g. 60 seconds, and a request limit. The tool tracks a rolling count of requests in the trailing window rather than since the last fixed boundary, which avoids the double-burst problem where two allowed bursts land back-to-back across a fixed-window edge. It flags which requests in your pattern exceed the limit and when.
Only if the gateway implements the same algorithm and parameters you entered. Many gateways use variants, such as fixed window or distributed counters with eventual consistency, that behave differently at the edges, so treat this as a planning aid, not a guarantee of production behavior.
The tool doesn't recommend one - it shows the behavior of each against your pattern so you can compare. Both allow bursts: token bucket lets a request burst consume however many tokens have accumulated, up to capacity, while sliding window lets requests burst up to the full window limit within any trailing window. Sliding window's advantage isn't a lack of burst allowance - it's that it avoids the fixed-window edge case where two full bursts land back-to-back across a boundary, briefly doubling the effective rate. The right choice depends on your traffic shape and your API's tolerance for burstiness.
The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.
Format, validate, and beautify JSON with syntax highlighting and error detection.
Encode text or files to Base64 and decode Base64 strings back to their original form.
Format and indent SQL queries for better readability across all major dialects.
Convert HTML markup into clean Markdown syntax with support for tables and lists.
Write Markdown and see the rendered HTML output in real time with live preview.
Visualize unified diffs and patch files with color-coded additions and deletions.