Explaining rate limiter designs: token bucket, sliding window and multi-server limits

A rate limiter checks on each request whether a client key, such as an IP, user, API key or tenant, has remaining allowance. Token bucket is the common default because it permits short bursts while enforcing a long-run rate, and a sliding window counter approximates a maximum count over any rolling window. In distributed setups, the shared state sits in a central store, and each check must run as one atomic operation to prevent concurrent requests from exceeding the limit. Over-limit clients receive HTTP 429 with a Retry-After header, and clients are advised to back off exponentially with jitter. The IETF RateLimit header fields remain an Internet-Draft as of November 2026.