Rate limiter

Protect an API from overload and abuse by rejecting excess requests early with 429. The design choices are the algorithm, where the counters live, and what happens when the limiter itself is slow or down.

Notes and ratings save in this browser. Completing self-assessment records your progress.

Duration 45:00

Requirements checklist

Limit requests per client (API key, user or IP) per rule, e.g. 100 requests/minute, with short bursts allowed.Rejected requests get 429 Too Many Requests with Retry-After and rate-limit headers.Rules are configurable per endpoint and per plan without a deploy.Adds under 1 ms p99 to each request.Limits hold across all API servers (a client cannot multiply its quota by hitting different servers), within a small tolerance.A limiter failure must not take the API down: decide fail-open or fail-closed explicitly.

Clarifying questions

What identifies a client: API key, user, IP?
Is the limit a hard quota (billing) or overload protection?
Are bursts allowed, and how large?
Must the limit be exact across all servers, or is a few percent of overshoot fine?
What should happen if the limiter is unavailable?

Open a practice canvas (new tab)Estimation calculators (new tab)

requirements

Suggested time: about 6 minutes. Explicit fail-open/closed policy and rule configurability.

Notes for requirements