APIs

Rate limiting: free-recall review

Crux Free-recall prompts across the rate-limiting unit. Answer each from memory first, then reveal the model answer and compare.

Your altitude — climbing toward senior

ZeroJuniorMiddleSenior

You are at senior altitude — in orbit

◷ 14 min

Retrieval beats re-reading. For each prompt, say or write a full answer from memory before you open the model answer — the effort of recall is what makes the tradeoffs stick when you are designing a limiter under pressure.

Goal

Reconstruct the unit’s spine — the boundary burst, the algorithm tradeoffs, the distributed-counter trap, atomicity, and the 429 contract — without looking back at the lesson.

Recall before you leave

01
Why does a fixed window leak a 2x burst, and how do the sliding window log and token bucket each remove it?
02
Compare the sliding window log and the sliding window counter. When is each the right call?
03
Explain how a token bucket enforces an average rate while still allowing bursts, and what the capacity parameter controls.
04
An in-memory limiter passes every test on a laptop but lets traffic far exceed the limit in production. Explain the failure and the fix.
05
Why run the Redis rate-limit check as a single Lua script instead of INCR then EXPIRE?
06
What does the 429 contract owe a well-behaved client, and why must RateLimit-Reset be delta-seconds rather than a UNIX timestamp?

Recap

If you could reconstruct each answer from memory, you hold the unit’s spine: fixed window leaks a 2x boundary burst that sliding window and token bucket each remove differently; the log is exact but memory-heavy while the counter approximates it for two integers; token bucket enforces an average while capacity sets the burst; a per-node counter is a lie behind a load balancer; the shared Redis counter must be updated atomically with Lua; and the 429 contract owes the client Retry-After in delta-seconds plus jitter to avoid a thundering herd.

Continue the climb ↑Rate limiting: code and snippet reading