Lesson 18 of 30

API Rate Limiting

Q: Your API client is getting 429 responses in production. What's happening, and how would you fix your client's behavior?

A strong answer covers: 429 means the client exceeded the server's allowed request rate for its window; Correct response: respect Retry-After / rate-limit headers, back off (ideally with exponential backoff and jitter) rather than retrying immediately; Consider whether the root cause is an actual bug (retry loop, runaway effect) rather than legitimate traffic growth.

A server-side cap on how many requests a client can make in a window of time — the backend's version of the JavaScript track's throttle, protecting shared infrastructure instead of a single browser tab.

11 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 2

A client receives a 429 response with `Retry-After: 30`. What should a well-behaved client do?

Switch to a different API key and continue at the same rateWait roughly the indicated time before retrying, ideally with backoffRetry immediately in a tight loop until it succeeds

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on API Rate Limiting

What interviewers actually ask about this, and what a strong answer has to cover.

Your API client is getting 429 responses in production. What's happening, and how would you fix your client's behavior?

A strong answer covers

429 means the client exceeded the server's allowed request rate for its window
Correct response: respect Retry-After / rate-limit headers, back off (ideally with exponential backoff and jitter) rather than retrying immediately
Consider whether the root cause is an actual bug (retry loop, runaway effect) rather than legitimate traffic growth

Likely follow-ups

What's the conceptual relationship between client-side throttle and server-side rate limiting?
What's the difference between a fixed window and a token bucket rate-limiting algorithm?
How would you design your own client code to proactively avoid hitting the limit, using the rate-limit response headers?

Practice these with the AI interviewer →

The plain-language idea

Rate limiting caps how many requests a single client (identified by API key, IP, or user id) can make in a given time window. Once the cap is hit, the server rejects further requests — typically with a 429 Too Many Requests status — until the window resets.

HTTP/1.1 429 Too Many Requests
Retry-After: 30
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1699999999

The response headers are the API telling you the rules directly: the total limit, how many requests you have left, and when the window resets — a well-designed API lets your client code respect the limit proactively instead of just reacting to 429s.

Rate limiting: capping how fast one client can call youStep 1 of 3

100 requests arrive from one client within a second — far more than the API can sustainably handle.

What people usually miss

Watch out

A well-behaved client handles 429 by backing off, not by retrying immediately. Respecting the Retry-After header (and often adding exponential backoff with jitter for repeated failures) is the correct response — retrying instantly just fails again and adds more load.
Rate limits protect against both malicious abuse and honest bugs. An infinite retry loop in your own code, or a runaway useEffect re-fetching on every render, can hit a rate limit just as easily as a real attacker — from the server's perspective, both look identical.
There's more than one algorithm — fixed window (simple, but can allow a burst right at the window boundary), sliding window, and token bucket (allows short bursts while enforcing a steady average rate) all make different tradeoffs between simplicity and burst tolerance.

Why this matters in interviews

"Your API client is getting 429s in production — what do you do?" is a real operational question, and the correct instinct (read the rate-limit headers, back off respectfully, don't just retry harder) shows practical experience integrating with real third-party or internal APIs.