Rate Limit Calculator

Calculate sustainable request rate under a token bucket rate limiter from bucket size and refill interval, including burst capacity.

Inputs

Bucket Sizetokens

Maximum tokens the bucket can hold, i.e. the maximum burst size.

Refill Intervalseconds

Time to refill the bucket from empty to full at the configured refill rate.

Cost per Requesttokens

Tokens consumed per request (usually 1, but can be weighted for expensive endpoints).

Sustained Allowed RPS

10.000requests/sec

Max Burst Requests

100.0requests

Sustained Rate

600.0requests/min

Token Refill Rate

10.000tokens/sec

Step by step

Sustained refill rate: bucket size ÷ refill interval
100 ÷ 10s
= 10.000 tokens/sec
Allowed RPS: refill rate ÷ cost per request
10.000 ÷ 1
= 10.000 req/sec
Max burst: bucket size ÷ cost per request
100 ÷ 1
= 100.0 requests

How it works

The token bucket algorithm allows short bursts up to the bucket's full capacity, while limiting the long-run sustained rate to the refill rate: allowed_rps = bucket_size ÷ refill_interval ÷ request_cost. A larger bucket size permits bigger bursts without changing the sustained rate, while a shorter refill interval increases the sustained rate a client can maintain indefinitely — the two parameters are independent knobs for burst tolerance versus steady-state throughput.

Formula

allowed_requests = rate_limit × window_seconds

rate_limit: Maximum requests per second allowed
window_seconds: Rate limit window duration (seconds)

Frequently Asked Questions

What's the difference between bucket size and refill rate?

Bucket size controls how large a burst is tolerated (how many requests can fire instantly after the bucket is full); refill rate (bucket_size ÷ refill_interval) controls the long-run sustained rate — they can be tuned independently to allow bursty traffic patterns while still bounding average load.

How is a token bucket different from a fixed window counter?

Fixed window counters reset abruptly at interval boundaries, which allows a client to send 2x the intended rate right at a window edge; token bucket (and its close relative, leaky bucket) smooths this out by continuously refilling, avoiding the edge-of-window burst problem.

What request cost should I use for expensive endpoints?

Weight expensive operations (e.g. bulk exports, complex search queries) with a higher token cost than simple reads, so the same bucket capacity naturally throttles resource-intensive requests more aggressively without needing a separate limiter per endpoint.

How do I choose bucket size for a good user experience?

Size the bucket to comfortably accommodate legitimate burst patterns (e.g. a page load firing several parallel API calls) while still being small enough that a misbehaving or malicious client can't cause a meaningful spike — profile real traffic patterns rather than guessing.

You might also need

Circuit Breaker Threshold Calculator API Gateway Throughput Calculator Ingress Controller Capacity Calculator