Redis is a good service to implement rate limiter, it's fast and east to support distributed system.

GET Get the value of key.

INCR Increments the number stored at key by one.

EXPIRE Set a timeout on key.

MULTI Marks the start of a transaction block.

EXEC Executes all previously queued commands in a transaction and restores the connection state to normal.

ZCOUNT Returns the number of elements in the sorted set at key with a score between min and max.

RPUSH Insert all the specified values at the tail of the list stored at key. If key does not exist, it is created as empty list before performing the push operation. When key holds a value that is not a list, an error is returned.

1. GET: [Redis key]:[current number]
2. if current number exceed RATE-LIMITER, return error (drop request)
3. MULTI:
   1. INCR [Redis key]:[current number]
   2. EXPIRE [Redis key]:[current number] 59 (1 min)
4. EXEC

2 key points

1. INCR on non-exist key will always be 1.
2. EXPIRE is inside a MULTI along with the INCR (means this is a atomic operation)

1. easy to implement

1. A burst of requests at the end of the window causes server handling more requests than the limit

1. Overcome fixed window's cons

1. It is not memory-efficient
2. It is very expensive because we count the user’s last window requests in each request.

1. Overcomes the cons of the fixed window by not imposing a fixed window limit and thus unaffected by a burst of requests at the end of the window.
2. Overcomes the cons of sliding logs by not storing all the requests(only the requests limited to queue size) and thus memory efficient.

1. Bursts of requests can fill up the queue with old requests and most recent requests are slowed from being processed and thus gives no guarantee that requests are processed in a fixed amount of time.
2. This algorithm causes traffic shaping(handling requests at a constant rate, which prevents server overload, a plus point), which slows user’s requests and thus affecting your application.

1. Overcomes the cons of the fixed window by not imposing a fixed window limit and thus unaffected by a burst of requests at the end of the window.
2. Overcomes the cons of sliding logs by not storing all the requests and avoiding counting for every request and thus memory and performance efficient.
3. Overcomes the cons of leaky bucket starvation problem by not slowing requests, not traffic shaping.

1. Overcomes all the above algorithms cons, no fixed window limit, memory and performance efficient, no traffic shaping.
2. No need for background code to check and delete expired keys.