Building a rate limiter, why even use Redis.

In this story, the author explains why using Redis to create a rate limiter is a better option than using a Node.js process or a standard database. When building a rate limiter from scratch, the author highlights several issues with using Node.js, such as race conditions and millisecond collisions. Race conditions occur when two requests hit within the same millisecond and read/write the same timestamps, bypassing the rate limit.

Millisecond collisions happen when two requests occur simultaneously, causing them to overwrite each other's data.

The author compares the use of a ZSET in Redis to simply using a map and array. A sorted array allows for O(logN) search time using binary search, but write-heavy operations like insertion and deletion can be costly (O(N) memory-copy operations). Redis uses a combination of a hash map and a skip list to achieve both fast lookups and efficient memory usage while performing write operations.

Traditional databases are not a viable solution because they suffer from concurrency bugs similar to Node.js. Most databases use Multi-Version Concurrency Control (MVCC), which allows stale reads while writes are in progress. This can cause the rate limit to be bypassed if a second request reads the uncommitted state before the first write finishes processing.

The express-rate-limit library, which is often used for rate limiting, also suffers from the boundary burst problem due to its fixed-window approach. This issue allows an attacker to send requests within the reset window, bypassing the limit.