Observing a harsher rate limit than defined about django-ratelimit HOT 2 CLOSED

Without higher precision in the log, this is what I believe is happening:

Your first request isn't at 00:34:38.000, so requests 1-5 are within one second. Then, since you're not waiting a full second after the 5th request, you're running into the second issue you describe.

There are two ways to deal with this. One is what happens right now: if requests keep coming in they keep getting blocked, because the TTL on the cache key is continuously pushed back.

The other is to treat the period as a window. So if the rate is 5/s, and someone is making 10 req/s, constantly, half of those will work, and half will get rate limited. If it's 60/m and they're making 10 req/s, they'll hit the limit after 6 seconds, but then 54 second later they can make another 60 requests.

I disliked that initially, but I've seen schemes like that used more in practice and have come around—or at least I'm more neutral now. The challenge is that you don't want all the windows to elapse at the same time, because then you get everyone who has been ratelimited free at the same time, which creates a thundering herd problem. So the scheme has to include some mechanism for staggering the windows.

from django-ratelimit.

Closing in favor of #48, which covers more specifics about how to do this.

from django-ratelimit.