Explain the concept of Rate Limiting algorithms and their use in web applications.

Official Answer

Rate limiting bounds requests or resource consumption over time. A useful design states the key, the budget and where enforcement happens. A per-account limit, a per-IP limit and a global expensive-operation limit solve different problems; an IP address is not a reliable user identity.

• Token bucket: replenish tokens at rate r up to capacity B. Each accepted request consumes a token. This permits bursts up to the available capacity while bounding the sustained average.
• Leaky-bucket queue: drain a bounded queue at a fixed rate. It smooths work but adds waiting time, so define the queue limit and maximum delay.
• Fixed window: count requests in each interval. It is simple but permits a burst across a boundary. Sliding-window methods reduce that boundary effect at additional storage or computation cost.

For a hypothetical API, start with a bucket of 20 tokens and refill 5 tokens per second. An instantaneous burst of 25 one-token requests admits 20 and rejects 5; after one second with no intervening requests, 5 tokens are available. This example assumes an atomic counter and a shared time basis. Independent buckets on each application server would multiply the effective limit.

For HTTP throttling, return 429 and explain the limit; a Retry-After header can tell a cooperative client when to try again. Test concurrent requests, clock/window boundaries, shared-IP users, retried operations and a failed limiter store. Choose fail-open or fail-closed behavior according to the endpoint's risk, and bound the fallback.

Measure legitimate-request rejection, admitted load, latency, error rate and resource saturation by endpoint and tenant. Rate limiting complements authentication, authorization and upstream attack protection; it cannot guarantee service availability against every denial-of-service attack.

Source

RFC 6585, section 4 defines HTTP 429 and Retry-After behavior.