Designing a flexible Rate limiter is a great way to control the usage of various aspects of your application.  Probably the most common usage would be to rate limit your public API by limiting client requests to x per minute.  It is also a good idea to guard certain user interactions with your web application, such as logging in or posting content.

At first glance you might think using a database for this, but in high load or multi-tenant environments it is always a good idea avoid the database as much as possible since requests per second tend to add up fairly quickly.  In my opinion Redis is a great data store for this type of feature, since it has a good mix of data types where you can tweak your design based on your requirements.

If you want to rate limit based on a time frame like say 5 minutes, you have to keep in mind that this 5 minute window can be abused if you don’t design things correctly.  For example, if you are rate limiting to 100 operations per 5 minutes, someone might make 99 requests in the first 4:59 seconds, and then make another 99 requests in the next 10 seconds, effectively making over 100 operations in a given sliding 5 minute window.  If that sounds like I am overthinking the purpose of rate limiting, it really depends on accurate you need to be based on your SLA with your client or internal thresholds.

A good practical example is how discourse has designed their Rate Limit class.

def performed!
  return if rate_unlimited?

  if is_under_limit?
    # simple ring buffer.
    $redis.lpush(@key, Time.now.to_i)
    $redis.ltrim(@key, 0, @max - 1)

    # let's ensure we expire this key at some point, otherwise we have leaks
    $redis.expire(@key, @secs * 2)
  else
    raise LimitExceeded.new(seconds_to_wait)
  end
end

You can take a look at their implementation here.

Internally the Rate limit class is using a List, and each operation adds an item to the list and trims the list in case it contains too many items.  A ‘key’ represents an operation that you are rate limiting, like say “user_login” or “api_get_user”.   It determines a given operation (or “key”) to have reached its rate limit threshold when the list has reached its maximum allowed count and examining the age of the oldest item added to list (see the method “is_under_limit?” for details.

As much as you might love your end users, whenever you expose an API or user interaction that involves using resources on your backend, you have to guard against use patterns that might effect the health of your application.