Your rate limiter counted the rejections. Now a retrying client never gets back in.

transcript

A customer hits your rate limit. They retry. And as long as they keep retrying, they never get back in.

Food delivery interview: someone places hundreds of orders. So you add rate limits, at four layers. 10 orders an hour per user. 100 requests a minute per IP address. 500 orders an hour per restaurant. That one protects something real: the kitchen. And 1,000 orders a second, globally. That protects the system itself.

Each limit is a sliding window in Redis. First, trim the attempts that slid out. Count what's left in the window. Then record this attempt. Simple. But here's the catch.

A user places their tenth order this hour. Allowed, and recorded. The eleventh is rejected. But you record that attempt too. Their app retries. Rejected. Recorded. The window stays full. Old attempts slide out. New retries slide in. They're over the limit indefinitely.

Record everything, and the rejections themselves keep the window full. So trim, count, and record only if it's under the limit. In one atomic step. Now rejections cost nothing. The window drains, and the user gets back in.

A rate limit should count what you let through. Count what you refused, and the limit never lets go.

Full breakdown in the lecture.