APIs
Rate limiting: multiple-choice review
Crux Multiple-choice synthesis across the rate-limiting unit — algorithm tradeoffs, the boundary burst, distributed counters, atomicity, and the 429 contract.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions that cut across the whole unit. Each mirrors a design call you make under real traffic — not a definition to recite, but a tradeoff to weigh when a customer is hammering your boundary across six nodes at once.
Goal
Confirm you can connect algorithm choice, burst behaviour, the distributed-counter trap, atomicity, and the 429 contract — the synthesis the lesson built toward.
Quiz
Completed
The limit is 100/min enforced with a fixed window keyed by {key}:{minute}. What is the worst-case number of requests a client can legitimately land in a ~1-second span, and why?
Heads-up A single window caps at 100, but the limiter has no memory across the reset edge. A client fills the end of one minute and the start of the next, so up to 2x lands at the boundary.
Heads-up Fixed windows do not average anything. Each window independently grants the full 100, so the worst case at the seam is 2x, not 1.5x.
Heads-up It does cap: the worst case is bounded at exactly 2x the limit, concentrated at the boundary. That known leak is the reason to reach for sliding window or token bucket, not evidence of no cap.
Quiz
Completed
A public API serves bursty browser clients — a page load fires ~12 requests at once, then idles. You want a fair average rate that tolerates those page-load bursts. Which algorithm fits best?
Heads-up Leaky bucket smooths output to a steady rate, which actively refuses the legitimate page-load burst and adds queuing latency. It fits a fragile downstream, not friendliness to bursty clients.
Heads-up Cheap, but it leaks a 2x boundary burst and does not model bursts intentionally — any tolerance is an accident of where the request lands in the window, not a tunable knob.
Heads-up Exact, but for high-volume bursty traffic the per-key memory of one timestamp per request is a heavy price for accuracy you do not need here. Reserve it for audit-grade counts.
Quiz
Completed
An in-memory limiter passes every test on a laptop, but in production traffic sails through far above the configured 100/min. Four app nodes sit behind the load balancer. What is the root cause?
Heads-up TTL length does not multiply the limit by the node count. The defect is that the counter is per-process; the limit must live in a store every node shares.
Heads-up The config is right per node; the bug is architectural. N in-memory counters silently sum to N times the configured limit regardless of the value.
Heads-up Sticky sessions would mask the bug by pinning a client to one node, but that is fragile and breaks fairness. The real fix is a shared counter in Redis, not session affinity.
Quiz
Completed
You move the counter to Redis and implement it as INCR followed by EXPIRE. Why is a single Lua script the more robust pattern?
Heads-up Speed is not the point — INCR is already sub-millisecond. The reason is atomicity: the script prevents interleaving and the TTL-less-key race.
Heads-up Lua scripts run in memory like any Redis command; persistence is orthogonal. The benefit is the atomic read-decide-update cycle.
Heads-up Redis runs commands single-threaded already; that is why a script executes with no other command interleaved. Lua leverages that property, it does not change it.
Quiz
Completed
An auth service must enforce an exact per-account limit for compliance — no boundary slack, every attempt accounted for. Which algorithm, and what is the cost you accept?
Heads-up For a coarse edge limit ~0.003% error is great, but it is still an approximation. An audit-grade exact count for compliance is the one case where you pay for the log.
Heads-up Fixed window is exact within a window but leaks up to 2x at the boundary, so the rolling count is not exact. That slack is unacceptable for an audited limit.
Heads-up Token bucket deliberately allows a bounded burst above the steady rate, so it does not enforce an exact rolling count. It optimises for friendliness, not audit-grade exactness.
Quiz
Completed
Under a fixed window you reject with 429 and a hard Retry-After of 30 seconds. At the next window edge your error rate spikes again. What happened and what is the fix?
Heads-up Key expiry is expected and correct; it does not cause a synchronized retry spike. The spike comes from handing every client the same Retry-After deadline.
Heads-up Shortening it just moves the synchronized wave earlier — all clients still retry together. The fix is to desynchronize them with jitter and a continuously-refilling model, not a smaller fixed delay.
Heads-up Here the clients are well-behaved — they obeyed Retry-After, which is exactly why they all woke at once. The herd is self-inflicted by an identical deadline, not by misbehaving clients.
Recap
The through-line: how requests fall into windows is where fixed window leaks its 2x boundary burst; sliding window log buys exactness with per-request memory, the sliding counter approximates it for two integers, and token bucket models bursts as a tunable capacity. None of it is real if the counter lives in per-node memory — share it in Redis, make the read-decide-update atomic with Lua, and when you reject, honor the contract with 429 + Retry-After in delta-seconds plus jitter so the reset edge does not become a thundering herd.