I orginally put this on LinkedIn , but realized I should probably contribute to Infosec Exchange.
If you've ever wondered what rate limiting from the back end looks like, here's an example.
The purple box is a command run on my local machine which sends 10 requests very quickly to an external server's web application.
The green box is the web server's Redis instance logging each "request".
First, the instance checks if the request IP address EXISTS. If not, it is SET as a key with a value of 1 and an expiration of X seconds, X being predetermined. Each request from that IP address will increment (INCR) the value by 1 if the key has not expired.
This instance data is used in a PHP script for each search to check if a key exists and if so, is its value greater than the limit defined in the script. If the limit has been exceeded, the script will not perform the search.
The blue box is a visual proof that the server has stopped returning the full request data due to the IP being rate limited.
If you look closely at the green box, you will notice there are multiple INCR. This is because the IP address is saved for an extended limit check.
There are issues with just limiting based off IP, but I'll address those further down the line. Things could be tricky since the web application does not require user registration.
I built this limiter from a variety of public documentation and hope to release it as an open source project at some point. Some of the documentation was vulnerable to simple bypasses, so there's likely a lot of by buggy limiters out there.
I'd prefer to not rate limit users, but with limited server resources, it seems like a wise move.