Rate limiting looks like a number in a box, a hundred requests per minute, until you implement it across three hundred POPs and discover the number was a distributed-systems problem wearing a policy costume. Algorithm choice and counting scope decide what your limits actually enforce.
The algorithm menu
Fixed windows count per interval and reset: simple, and burstable to double the limit at boundaries (sixty requests at 11:59:59, sixty more at 12:00:00). Sliding windows smooth the boundary by weighting adjacent intervals. Token buckets refill capacity at a steady rate and permit configured bursts, the shape most APIs actually want: sustained rate plus forgiveness for legitimate spikes. Leaky buckets enforce smooth output, better for protecting fragile downstreams than for policing clients. Know which your platform runs; vendors differ and documentation euphemizes.
The distributed counting truth
A global limit implies a global counter, and a global counter at edge scale is either slow (synchronous coordination), approximate (async aggregation with lag), or scoped smaller (per-POP counting). Per-POP limits multiply your intended ceiling by the number of POPs an attacker can reach, which for anycast is many. Interrogate the scope explicitly: is the limit per node, per POP, or genuinely global, and with what aggregation delay? The honest answers shape what your limits mean under actual attack.
The layered-defense framing keeps rate limiting honest about its job: it is not your DDoS mitigation (volumetric attacks are absorbed lower in the stack), and it is not your bot management (sophisticated automation stays politely under limits while doing damage). Rate limiting’s actual jobs are protecting origin capacity from legitimate-but-excessive use, enforcing commercial API tiers, and blunting unsophisticated abuse cheaply. Estates that ask it to do the other layers’ jobs end up with limits too tight for real users and too naive for real attackers, the worst point on the curve. Right-sized, it is boring, effective capacity policy; that is the compliment.
Keys, responses and legitimacy
Limit keys deserve design: raw client IP punishes carrier NAT and corporate egress (thousands of humans, one address); API keys and session tokens key fairly but require auth-layer cooperation; composite keys (token where present, IP as fallback) serve mixed estates. On breach, respond with 429 plus Retry-After and rate-limit headers so well-behaved clients back off cleanly, misbehaving ones ignore you identically either way, and reserve silent throttling or tarpitting for adversarial traffic classified by the bot layer, not the rate layer.
In practice
Set limits from measured legitimate percentiles (p99.9 of real users, then headroom), not from folklore; alarm on limit-hit rates by key class so tightening and attacks are distinguishable; and load-test the limiter itself, because a rate limiter that degrades under the traffic it exists for is ornamental. Then document the counting scope next to every limit, so the next engineer inherits enforcement semantics, not just numbers.
API-edge reviews here include limiter verification under load and a counting-scope audit. The scope finding is usually news.