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.
