Designing an API Rate Limiter

Can you explain why 20 B for Redis hash overhead ? It's the biggest component in memory estimation, yet it's not explained.

Perhaps this is out of scope for the question, but I’m interested to know how we could expand upon this design for a public API with the specific goal of maintaining system availability during a DDOS attack? Rate limiting on a per-IP level could be insufficient to stop a distributed attack, and rate limiting on a system-wide level could render the system unavailable to well-intentioned users due to the attack load.

Regarding the first algorithm, i don't think this is a fixed size algorithm, it's a sliding window, since the start time is reset to current time each time we get a new request that is out of the 1 minute window of the previous limiting period.

also if we take the example shown here in the article to explain the benefits of the sliding window, the first algorithm prevents that case.

|_____t1_t2 | _t3 _t4 ___t8|

the start time will be set to the time of the first t1, t3 and t4 will be throttled because a minute hasn't passed since start time which is set to t1, requests will be accepted only after t1 + 1 minute (demonstrated here as t8) which will also reset the value for start time

Not clear to me, how we are dealing with race conditions in these three mentioned approaches?

Fixed window mentions 4 bytes for custom "locking" logic, but it doesn't elaborate more. I am assuming some sort of 2 phase commit will be needed but maybe there's another trick?

In sliding window with counters, how to find the nearest timestamp compared to current timestamp if using redis hash ?

In the Sliding Window With Count approach, why do we need to store the counts for all 60 minutes? We only need to store it for one minute, and keep aggregating the hourly count to enforce the hourly limit. That would reduce our storage requirements to roughly match the fixed minutely window approach with some extra per-user storage for hourly usage. What am I missing?

What exactly is stored in the rate limiter databases? Why would this permanent storage be needed? Would it be a bad idea to have the rate limiter run entirely in memory, with no database backing? Worst case scenario, some users could potentially get double the allowable rate if a machine goes down after the user maxes out - this seems like it could often be acceptable to get a much simpler system.

In the diagram in section 7, why does the rate limiter sit between the webserver and databases? Shouldn't the API servers be connected to the databases instead of the rate limiter?

Can you elaborate on how this was arrived at?

if we assume a rate limit of 10 requests per second, this would translate into 10 million QPS for our rate limiter! This would be too much for a single server.

Why would it be too much? Is there a calculation that shows this?

Sliding Window algorithm would not have the concurrent request issue? Lock would still be needed, could be a case where both read at the same time and both write at the same time which could result to 4 records per minute.