Services

Resources

Company

Rate limiting

Rate limiting is a control that caps how many requests a client, user or service can make within a time window. Requests over the limit are rejected, queued or slowed down. APIs use it to protect shared capacity and keep one caller from starving others. Over HTTP, a rejected request usually gets status 429 Too Many Requests.

How it works

A token bucket is the most common algorithm. Each client has a bucket that refills at a fixed rate and holds a maximum number of tokens. Each request spends one token. For example, a limit of 100 requests per second with a bucket size of 200 allows a burst of 200 requests, then a steady 100 per second. A fixed-window limit instead counts requests per minute and resets the count at the minute boundary. Servers often send a Retry-After header that tells clients when to try again.

Why it matters in production

Without limits, one noisy client or retry storm can overload a service for everyone. Callers also need to handle limits well. A client that batches requests and retries with exponential backoff and jitter keeps working, while one that sends every item as a separate request gets throttled and may drop data.

See also

On the One2N blog

References

  1. Handling overload (Google SRE book)

  2. RFC 6585: Additional HTTP status codes (429)

Comic about rate limiting: a batch job floods the API and Pat's checkout times out; a token bucket refills 100 per second and holds 200 so 300 of 500 requests get 429; per-client buckets keep Pat at 200 OK; Kai batches 100 items and retries with backoff and jitter.