Why it matters
Every public API needs rate limiting. Wrong algorithm creates unfair experiences (bursty vs steady traffic treated differently). Missing enforcement point lets attackers bypass. Getting this right is table stakes.
The architecture
Token bucket: tokens refill at rate R up to capacity C. Each request consumes tokens. Allows short bursts up to C, sustained rate R. Standard for API rate limiting.
Leaky bucket: fixed rate of processing, queue in front. Smooths bursts. Good when downstream can only process at fixed rate.
How it works end to end
Fixed window: count requests per calendar minute. Simple but allows 2x limit at window boundaries.
Sliding window log: precise per-window count. Expensive at scale.
Sliding window counter: hybrid of fixed and log. Cheap and mostly accurate.
Distributed rate limiting: for horizontally-scaled services, use Redis for shared counters. Care needed for latency and single-point-of-failure.