Cap the rate at which a user / IP / API key can hit a service.

Data Flow (token bucket)

bucket holds N tokens
refills at rate R tokens/sec

request -> if bucket >= 1: consume, allow
           else: reject (HTTP 429)

Algorithms

• Token bucket: stores N tokens; refills at rate R. Allows bursts up to N.
• Leaky bucket: smooths a burst into constant output rate.
• Fixed window: simple counter that resets every minute; bursts at boundaries.
• Sliding window: tracks requests in the last N seconds (more accurate, more memory).

Pitfalls

• Fixed-window edge bursts (2x the limit at the window boundary).
• Storing counters in the DB kills latency; use Redis.
• No Retry-After header on 429s, so well-behaved clients hammer again.

Code (token bucket, simple)

class TokenBucket:
        def __init__(self, rate, capacity):
            self.rate = rate
            self.cap = capacity
            self.tokens = capacity
        self.last = time.monotonic()
 
    def allow(self):
        now = time.monotonic()
        self.tokens = min(self.cap, self.tokens + (now - self.last) * self.rate)
        self.last = now
        if self.tokens >= 1:
            self.tokens -= 1
            return True
        return False

Analogy

A turnstile at a stadium: refills with tokens, lets one person per token. Bursts allowed up to capacity.

Interview tip: Specify rate, capacity, and what HTTP header you send back on rejection.