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
The gotchas of OTel collector processors for effective observability in K8s
Why your architecture should start with questions, not boxes
References
