What is rate limiting and how to protect an API from excessive requests?
Published on 2026-10-20 by frfrand
Qué es rate limiting, límites por usuario e IP, respuestas 429, ventanas temporales y cuándo puede perjudicar usuarios legítimos.
Rate limiting is a technique that limits how many requests a client can make during a period or under certain rules. It is used to protect APIs, prevent abuse, and distribute reasonably a capacity that is not infinite.
If someone sends thousands of requests per second to your login form, you might not want all of them to be served without restrictions.
A comparison with museum entries
Imagine a museum with space for one hundred simultaneous visitors. If it lets a thousand people in at once, the experience becomes bad for everyone.
Request limits serve a similar purpose: they allow managing the access rate so that a very active client does not consume all the service resources.
But an unfair policy must be avoided. If several families arrive on the same bus, blocking them because they share a source address would also be a mistake.
What can be limited?
You can establish rules by IP address, authenticated account, API token, or endpoint type. Each alternative presents trade-offs.
Limiting only by IP can affect people who share a residential, corporate, or mobile connection. Limiting by user requires identifying them. For critical endpoints, several combined strategies can be applied.
Business logic influences: querying a public product does not cost the same as generating a heavy report or sending an email.
How is it implemented?
A simple strategy is to allow a certain number of requests within a time window. There are also models such as token bucket, which allow controlled bursts and recover capacity progressively.
There is no need to memorize the formulas to understand the goal: establish a sustainable rate without unnecessarily punishing legitimate visitors.
In systems with multiple servers, coordination matters. If each instance counts requests separately, adding instances can accidentally multiply the allowed limit.
What is HTTP error 429?
When a client exceeds the policy, the server can return status 429 Too Many Requests. Some responses include Retry-After to indicate when it is appropriate to try again.
The client application should respect the limits and not retry in an aggressive loop. Otherwise, a system that is trying to protect itself will receive even more traffic.
Rate limiting and DDoS are not the same
Application limits help with certain abuses, but they cannot always stop a volumetric attack that saturates the network before reaching your server.
For those scenarios, upstream defenses, distribution networks, and specialized services are important. Rate limiting is a layer, not a magic solution against all threats.
Example: a report generation API
An API allows exporting reports that take twenty seconds to prepare. You can limit the number of concurrent jobs per account and move generation to a queue.
This protects the server and prevents one person from accidentally launching hundreds of identical jobs. Instead of returning unexpected errors, the system can inform that the task was scheduled or that a quota was temporarily reached.
Common errors
An identical limit for all routes: a status query and a costly export do not have the same needs.
Not explaining the rejection: the client interprets 429 as a crash if they do not know when to retry.
Blocking by IP without context: legitimate users behind the same network end up affected.
Trusting the limit as authorization: a person without permissions should not be able to perform an operation even once.
How to apply it in ArduMaker?
In an API deployed on an ArduMaker VPS, you can implement limits in the backend or in a compatible proxy, considering how many instances exist and where the counter is shared. Redis can participate in certain designs, although the exact choice depends on the architecture.
In one sentence: rate limiting allows saying "up to here, for now" to protect service availability. It works best when it responds to the real cost of each action and does not become an obstacle for legitimate users.
Sources: RFC 6585: status 429 · Retry-After header.