api-rate-limiting

Use the express-rate-limit middleware with a windowMs and max request count, then apply it to your routes with app.use. It returns 429 responses with standard rate limit headers when clients exceed the limit.

Token bucket handles traffic bursts smoothly but uses memory per user, while sliding window is more accurate at the cost of higher memory usage. Fixed window is simplest but allows boundary spikes where limits can be doubled at window edges.

Use Redis as a shared store for distributed rate limiting so all server instances enforce the same counters. In-memory buckets only work for single-process deployments and reset on restart.

Return X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset on normal responses, and a 429 status with a Retry-After header when the limit is exceeded. This lets clients back off gracefully.

Assign each tier its own quota, such as 100 requests per hour for Free, 1,000 for Pro, and 10,000 for Enterprise. Look up the user's tier from their API key or session and apply the matching limiter configuration.