Rate limit library
Fixed window limits—such as 3,000 requests per hour or 10 requests per day—are easy to state, but they are subject to have spikes at the edges of the window, as available quota resets. Consider, for example, a limit of 3,000 requests per hour, which still allows for a spike of all 3,000 requests to be made in the first minute of the hour, which might overwhelm the service.
Starts counting time windows when the first request arrives.
Same as Fixed Window rate limit but truncates the rate limit window to the rate interval configured in order to adjust to real time intervals passing. E.g:
- Rate limit interval is configured for new windows every 10 seconds
- First request arrives at
2022-02-05 10:23:23 - Current rate limit window: from
2022-02-05 10:23:20to2022-02-05 10:23:30
Works as any other fixed-window rate limiter. However, the meaning of 'capacity' of the inner fixed-window rate limiter changes from the total amount of requests that can be made to the total amount of tokens (points) that can be spent in that same window. This variant is particularly useful, for instance, when working on the crypto game field as many crypto exchanges employ this strategy. Take for example, binance.
You can refer to google architecture docs to read more about rate limits.
- Memory. Useful for non-distributed applications and testing purposes. Do not use on production unless you deliberately don't care about keeping rate limit state.
- Redis. github.com/go-redis/redis is employed as Redis client
- Token bucket rate limit
- Leaky bucket rate limit
- Composite rate limit
- Service rate limit