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