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)

Four-panel comic explaining Rate limiting. Rate limiting is the practice of capping how many requests a client or service can make in a time window, rejecting or delaying the excess.