Turn a rate limit into token-bucket parameters.
Refill rate
1.67/s
Bucket capacity (max burst)
120 req
Refill empty → full
1.2m
Token bucket parameters
capacity = 120 tokens · refill = 1.6667 tokens/secOne token regenerates every 0.6s. In Redis, implement this atomically with a Lua script (or the CL.THROTTLE command from RedisBloom) so the check-and-decrement can't race across instances.
Token bucket smooths bursts and is the usual default. A fixed window is simpler but lets a client send up to 2× the limit around a boundary; a sliding-window log is exact but stores every timestamp. Pick based on how strict and how memory-heavy you can afford to be.
Enter the requests you want to allow per second, minute, hour, or day, plus any extra burst headroom, to get the token-bucket parameters to configure: the refill rate (tokens per second), the bucket capacity (maximum burst), and how long an empty bucket takes to refill. Token bucket is the default choice because it separates the sustained rate from short bursts.
The tool also shows how often a single token regenerates and notes how to implement the check-and-decrement atomically in Redis so it stays correct across multiple app instances. Use it to size an API rate limit before you write the limiter, and to reason about the trade-off between token bucket, fixed window, and sliding-window log.
A fixed window resets its counter on a boundary, so a client can send the full limit at the end of one window and again at the start of the next — up to 2× the intended rate in a short span. Token bucket refills continuously, smoothing bursts to a steady sustained rate while still allowing a controlled burst up to the bucket capacity.
Do the check-and-decrement atomically so concurrent requests across instances cannot both pass. Use a Lua script that reads the token count, refills based on elapsed time, and decrements in one round trip, or use a purpose-built command like RedisBloom’s CL.THROTTLE. A plain GET-then-SET has a race window and will over-admit under load.