5 exercises on rate limiting — token bucket, leaky bucket, sliding window, and Retry-After headers.
0 / 5 completed
1 / 5
How does the token bucket algorithm work?
Token bucket: if 10 tokens refill per second with a bucket capacity of 50, a client can burst 50 requests instantly (if accumulated) but sustains only 10/s long-term. It is flexible and burst-friendly, used by AWS API Gateway and many CDNs.
2 / 5
How does the leaky bucket algorithm differ from token bucket?
Leaky bucket: requests enter a queue (the bucket) and are processed at a fixed rate — excess requests are queued or dropped. This enforces a constant output rate, useful for protecting downstream services that cannot handle bursts.
3 / 5
What makes the sliding window algorithm more accurate than fixed-window counting?
Sliding window: a fixed window allows a client to make 100 requests at 11:59 and 100 more at 12:00 — 200 in two seconds at the boundary. A sliding window measures the past 60 seconds from now, preventing this double-burst vulnerability.
4 / 5
What does the HTTP 429 Too Many Requests response indicate?
429 Too Many Requests: servers should accompany this with a Retry-After header (seconds to wait) or X-RateLimit-Reset (Unix timestamp). Well-behaved clients back off immediately; poorly written clients that retry instantly cause thundering herd.
5 / 5
What does the Retry-After header communicate to a client?
Retry-After: can be a number of seconds (Retry-After: 30) or an HTTP date. Respecting it enables polite back-off. Combining exponential backoff with jitter on top of Retry-After prevents all clients from retrying simultaneously after a rate-limit window resets.