How do I add rate limiting to a local Express server for testing?

Install the express-rate-limit package and apply it as middleware: const limiter = rateLimit({ windowMs: 60000, max: 10, standardHeaders: 'draft-7' }); app.use('/api/', limiter). This limits each IP to 10 requests per minute and automatically returns 429 with standard rate limit headers (RateLimit-Limit, RateLimit-Remaining, RateLimit-Reset). Customize the handler option to return your specific error response format. You can create different limiters for different endpoint groups (auth, search, write operations).

How should my client handle 429 rate limit responses?

Implement a fetchWithRetry function that checks for status 429, reads the Retry-After header (in seconds), waits that duration, then retries. Set a maximum retry count (typically 3) to prevent infinite loops. Use exponential backoff if no Retry-After header is present. After exhausting retries, throw a typed RateLimitError that the UI layer catches to show an appropriate message. Never retry immediately—always respect the server's backoff signal. In the UI, show a countdown timer based on Retry-After so users know when they can try again.

How do I use k6 or Artillery to test rate limit behavior?

With k6, use the constant-arrival-rate executor to send requests faster than your rate limit allows: { executor: 'constant-arrival-rate', rate: 50, timeUnit: '1s', duration: '30s' }. Track 429 responses with a custom Counter metric and verify responses include Retry-After headers. With Artillery, define phases that ramp from below-limit to above-limit rates. Both tools let you verify that rate limit headers are present, the 429 response body is correct, and the server recovers after the window resets.

What rate limit headers should my API return?

Return these headers on every response (not just 429s): X-RateLimit-Limit (total requests allowed per window), X-RateLimit-Remaining (requests remaining in current window), and X-RateLimit-Reset (Unix timestamp when the window resets). On 429 responses, also include Retry-After (seconds to wait before retrying). The draft-7 standard uses RateLimit-Limit, RateLimit-Remaining, and RateLimit-Reset without the X- prefix. Including these headers on successful responses lets clients implement proactive throttling before hitting the limit.

How do I test the user experience when rate limits are hit?

Use Playwright or Cypress route interception to force 429 responses with Retry-After headers: page.route('**/api/**', route => route.fulfill({ status: 429, headers: { 'Retry-After': '30' }, body: JSON.stringify({ error: { code: 'RATE_LIMIT_EXCEEDED' } }) })). Then assert that the UI shows: (1) a clear 'too many requests' message, (2) a countdown timer based on Retry-After, (3) a disabled retry button that re-enables after the wait period. This verifies the full end-to-end rate limit experience without needing a real rate-limited server.

Simulating Rate-Limiting in Local Testing