Why Rate Limiting Matters Before You Need It
Rate limiting is infrastructure that looks optional until the moment it becomes critical. An unprotected API is vulnerable to accidental overload from a misconfigured client, intentional abuse from scrapers or attackers, and the thundering herd problem when a high-traffic event sends a sudden spike of requests. Adding rate limiting after an incident is always more painful than building it in from the start.
In Node.js APIs, rate limiting typically lives at one of three layers: at the edge (CDN or load balancer), at the application middleware level, or within specific endpoints. The right approach depends on your architecture, but having at least application-level rate limiting is a baseline any production API should meet.
Basic In-Memory Rate Limiting with express-rate-limit
For Express APIs, express-rate-limit is the standard starting point. It is simple to configure, well-maintained, and handles the common cases without requiring external dependencies.
A basic setup limits each IP to a defined number of requests per window. You configure the window duration, the maximum requests allowed, and the response sent when the limit is exceeded. The middleware attaches to your router or to specific routes where you want protection.
The limitation of in-memory rate limiting is that it does not work across multiple instances. If your API runs on three servers, each server maintains its own rate limit counters independently. A client can send three times the intended limit by distributing requests across servers. For single-instance deployments this is fine. For horizontally scaled APIs, you need a shared store.
Distributed Rate Limiting with Redis
The standard solution for distributed rate limiting is to store counters in Redis, which is shared across all instances. The rate-limit-redis package provides a store adapter for express-rate-limit that uses Redis as the backing store.
The Redis INCR command is atomic, which means counter increments from multiple concurrent requests are handled correctly without race conditions. Combining INCR with EXPIRE gives you a sliding or fixed window counter that resets automatically. For most use cases, a fixed window implementation is sufficient and simpler to reason about.
For more sophisticated algorithms, the token bucket and sliding window log approaches provide smoother rate limiting behavior that avoids the traffic spike at window boundaries that fixed windows can create. The upstash-ratelimit library provides clean implementations of these algorithms with Redis or Upstash as the backing store, and the API is simpler than rolling your own.
Rate Limiting by Identifier
IP-based rate limiting is the default but not always the right identifier. For authenticated APIs, rate limiting by user ID is more accurate because it handles NAT and proxy scenarios where multiple legitimate users share an IP. For API key-based services, rate limiting by API key lets you set different limits for different tiers.
The generator function in express-rate-limit lets you customize the key used for rate limiting. A common pattern is to fall back through a priority order: authenticated user ID first, then API key, then IP address. This gives you accurate rate limiting for authenticated users while still protecting unauthenticated endpoints from abuse.
Graduated Response and Retry-After Headers
Binary rate limiting, either full access or a 429 error, is not always the best user experience. A graduated approach warns clients as they approach the limit and provides clear information about when they can retry.
Include rate limit headers in every response: X-RateLimit-Limit (the maximum allowed), X-RateLimit-Remaining (requests remaining in the current window), and X-RateLimit-Reset (when the window resets as a Unix timestamp). When returning a 429, include a Retry-After header with the number of seconds until the client can retry. Well-behaved clients will respect this and back off automatically.
Rate Limiting at the Edge
Application-level rate limiting is necessary but not sufficient for high-traffic APIs. Requests that hit your rate limit still reach your application servers, consume connection pool capacity, and generate responses. For APIs under significant load or targeted abuse, edge-level rate limiting prevents traffic from reaching your origin at all.
Cloudflare Rate Limiting, AWS WAF, and most load balancers support rate limiting rules that block traffic at the network edge. This is the right place to handle very high volume limits like preventing a single IP from making more than 1000 requests per minute, while application-level limits handle the finer-grained per-user or per-endpoint constraints.
Testing Your Rate Limiting
Rate limiting is the kind of feature that is easy to implement incorrectly and hard to notice until it fails. Load testing tools like k6 or autocannon let you verify that limits kick in at the right thresholds, that distributed counters work correctly across instances, and that responses include the right headers. Include rate limit behavior in your API integration tests so regressions are caught automatically.