How to Implement Rate Limiting in Node.js

Without rate limiting, a single client can send thousands of requests per second to your API. This can exhaust your server resources, crash your database, run up your cloud costs, and make the service unavailable to legitimate users. Rate limiting restricts how many requests a client can make in a defined time window, protecting your infrastructure and ensuring fair usage.

Install the express-rate-limit package from npm. This is the standard rate limiting middleware for Express applications. It works by tracking request counts per client identifier, which is the client's IP address by default, using an in-memory store. For production applications with multiple server instances, you must replace the in-memory store with a shared store like Redis.

Call rateLimit with a configuration object specifying windowMs as the duration of the time window in milliseconds and max as the maximum number of requests allowed per client in that window. Set a standardHeaders option to true so the middleware automatically adds RateLimit headers to responses informing clients of their limit, remaining requests, and reset time.

Authentication endpoints like login and password reset are high-value targets for brute force attacks. Create a separate, much stricter rate limiter for these routes with a smaller max value and a longer windowMs. Apply this limiter only to the specific routes rather than globally. Five attempts per fifteen minutes is a common starting point for login endpoints.

The default in-memory store does not work correctly when your application runs across multiple server instances because each instance has its own separate counter. Install rate-limit-redis and configure your rate limiter to use a Redis store. All instances share the same counter in Redis, ensuring consistent rate limiting across your entire fleet of servers.

IP-based rate limiting can be too broad in environments where many users share the same IP, such as corporate networks or mobile carriers. For authenticated endpoints, use the authenticated user's ID as the rate limit key instead of or in addition to the IP address. This provides more granular and fair rate limiting that accurately targets individual users.

When a client exceeds the rate limit, return a 429 Too Many Requests status code. Include a Retry-After header indicating how many seconds the client should wait before making another request. Include a descriptive message in the response body explaining that the rate limit was exceeded. This helps legitimate clients with retry logic and debugging tools understand what happened.

Log every rate limit exceeded event with the client identifier, the endpoint being limited, and the timestamp. High rates of 429 responses on the login endpoint indicate a brute force attack in progress. High rates on other endpoints may indicate a misconfigured client or a scraping bot. Set up monitoring alerts to notify your team when rate limit violations exceed a threshold so you can respond quickly.