A public API can receive requests from anyone.
That creates an obvious problem:
What stops one client from sending millions of requests?
Rate limiting.
Basic Idea
Suppose an endpoint allows:
100 requests per minute
A client that exceeds that limit might receive:
429 Too Many Requests
Why Rate Limit?
Rate limiting can help protect against:
- Accidental request floods
- Resource exhaustion
- Credential abuse
- Automated scraping
- Some denial-of-service scenarios
- Brute-force attempts It isn't a complete security solution, but it is an important layer.
Example
A simple policy could be:
GET /api/products
100 requests/minute
while a sensitive endpoint might use:
POST /api/login
10 requests/minute
Different endpoints often deserve different limits.
Where Should Limits Be Applied?
Possible strategies include limiting by:
IP address
User ID
API key
Session
Combination of identifiers
The appropriate strategy depends on the application.
Distributed Systems
If your application runs on multiple servers, an in-memory counter on each server can produce inconsistent results.
For example:
Server A → 50 requests
Server B → 50 requests
The user may effectively get 100 requests even though the intended limit was 50.
Shared infrastructure such as Redis is commonly used for distributed rate limiting.
Good User Experience
Rate limiting should be predictable.
API responses can communicate when clients should retry using appropriate headers and status codes.
Final Thoughts
Rate limiting isn't only a cybersecurity feature.
It is also a reliability mechanism.
A well-designed API protects itself from both malicious and accidental traffic spikes.
Top comments (0)