Why Rate Limiting?
Without rate limiting, your API is vulnerable to:
- DDoS attacks - Overwhelming your server
- Brute force attacks - Password guessing
- Scraping - Unauthorized data extraction
- Cost overruns - Excessive API calls
Rate Limiting Strategies
1. Fixed Window
- Simple to implement
- Count requests in fixed time windows
- Example: 100 requests per 15 minutes
2. Sliding Window
- More accurate than fixed window
- Smoother rate limiting
- Prevents burst at window boundaries
3. Token Bucket
- Allows controlled bursts
- Tokens regenerate over time
- Good for variable traffic patterns
Implementation Options
express-rate-limit (Simple)
Best for single-server deployments:
- Easy setup
- In-memory storage
- Good for getting started
Redis-Based (Scalable)
Best for distributed systems:
- Works across multiple servers
- Persistent rate limit counts
- Production-ready
Different Limits for Different Endpoints
Apply stricter limits on sensitive endpoints:
| Endpoint | Rate Limit |
|---|---|
| /api/auth/login | 5 per 15 min |
| /api/auth/register | 3 per hour |
| /api/general | 100 per min |
| /api/search | 30 per min |
Best Practices
- Different limits for different endpoints
- Use Redis for distributed systems
- Return helpful error messages with retry-after
- Include rate limit headers in responses
- Log rate limit violations for monitoring
- Consider tiered limits for paid users
Response Headers to Include
- X-RateLimit-Limit: Maximum requests allowed
- X-RateLimit-Remaining: Requests remaining
- X-RateLimit-Reset: When the limit resets
- Retry-After: Seconds until retry (on 429)
Need Help Securing Your API?
I build secure, production-ready APIs with proper rate limiting, authentication, and monitoring. Let's discuss your project.