Rate Limiting
Bounding how many requests a caller may make in a window, to protect capacity and enforce fair use.
Three purposes that are worth distinguishing because they need different limits: protecting the system from overload, protecting tenants from each other, and enforcing a commercial plan.
Algorithms in increasing order of fidelity: fixed window is trivial but allows a double burst across the boundary; sliding window fixes that; token bucket is the usual choice because it permits a controlled burst while bounding the sustained rate; leaky bucket smooths output to a constant rate.
Two implementation notes that matter. In a multi-instance deployment the counter must be shared,
or the effective limit is the configured limit times the instance count. And a rejection should
say so properly — HTTP 429 with a Retry-After header — so that well-behaved clients back off
rather than retrying immediately.