Q14 of 22 · Scenarios

How would you test a rate-limited API?

ScenariosMidscenarioapirate-limitingsecurityperformance

Short answer

Short answer: Clarify the limit type (per user, IP, key), window strategy (sliding vs tumbling), and response format. Then assert the limit boundary, 429 response and headers, window reset, and resistance to bypass via header spoofing.

Detail

Clarify first

  • What is the limit: requests per second, per minute, or per hour?
  • Is the limit applied per user, per IP address, per API key, or some combination?
  • Is the window sliding (rolling last N seconds) or tumbling (fixed clock interval)?
  • What does the response look like when the limit is exceeded — status code, headers, body?

Functional

  • Requests within the limit succeed with correct 2xx responses
  • The Nth request succeeds; the (N+1)th request within the window returns 429
  • A Retry-After (or X-RateLimit-Reset) header is present in the 429 response and accurately reflects when the window resets
  • After the window resets, requests succeed again up to the new limit
  • Two users sharing the same IP are not sharing limits if the limit is per-user (and vice versa)

Negative / error handling

  • A burst of requests at exactly the limit boundary — the (N+1)th is reliably rejected, not flakily passed
  • Rate limit counter resets correctly at the window boundary — not a clock-skew race
  • 429 response body contains a useful message (not a generic server error)

Edge & boundary

  • Exactly at the limit: Nth request succeeds, (N+1)th fails, (N+1)th after window reset succeeds
  • Distributed clients: two API keys each sending half the per-key limit simultaneously
  • Tumbling vs sliding window boundary: rapid burst in the last second of a window carries over to the next (only for sliding windows)

Security

  • Rate limiting is applied before authentication to prevent enumeration attacks on the auth endpoint
  • Cannot be bypassed by rotating the X-Forwarded-For header (IP spoofing) — server validates the real client IP
  • Limit enforced consistently for authenticated and unauthenticated requests

Performance

  • Latency at the rate limit threshold — does the server slow down as it approaches the limit, or does it cut off cleanly?

Close: automate limit boundary assertion, 429 status and header validation, and window reset. Load test for concurrent burst behavior and window-boundary precision — these are harder to cover with a single-threaded test.

// WHAT INTERVIEWERS LOOK FOR

The X-Forwarded-For spoofing bypass check and the distinction between per-user vs per-IP limits. The Retry-After header validation. Awareness that the limit boundary is the interesting test, not just 'it returns 429 eventually.'

// COMMON PITFALL

Only sending enough requests to see a 429 and calling it tested. Missing the boundary precision (Nth passes, N+1 fails), window reset behavior, and bypass via IP header spoofing.

// Related questions

How would you test a REST API endpoint?

Scenarios