Rate Limiting Pattern
API abuse prevention with multiple algorithms (fixed window, sliding window, token bucket), in-memory and Redis-based implementations, and per-endpoint configuration.
What's Included#
- In-memory fixed window rate limiter for single-instance deployments
- Redis-based rate limiter using Upstash for distributed environments
- Sliding window rate limiter for accurate sustained traffic control
- Token bucket algorithm for burst-tolerant limiting
- Rate limit middleware with per-endpoint configuration
- Per-user rate limiting with tiered plans
- Standard response headers (X-RateLimit-Limit, X-RateLimit-Remaining, Retry-After)
Usage#
Via CLI#
Loading code block...
Via AI Assistant#
Ask your AI assistant:
- "Use the API rate limiting pattern from Bootspring"
- "Apply the Bootspring rate limiting pattern to my project"
Key Considerations#
- Use Redis for production deployments since in-memory limiting does not work across multiple instances
- Set different limits per endpoint type (auth endpoints need stricter limits)
- Provide higher limits for authenticated and premium users
- Always include rate limit headers in responses to help clients implement backoff strategies
- Use sliding windows over fixed windows for more accurate sustained traffic measurement
- Return clear 429 error messages with Retry-After headers when limits are exceeded
Related Patterns#
- Middleware - Request preprocessing
- Error Handling - Consistent error responses
- Route Handler - API endpoint implementation