Rate limiting: plainly explained.

Rate limiting is a technique that caps how many requests a client (a user, an API key, or an IP address) can send to a server within a given time window, and rejects or delays the requests that exceed that cap. It protects APIs, login forms, and search endpoints from being overwhelmed by traffic spikes, scraping, brute-force attempts, or a single misbehaving script, while keeping the service responsive for everyone else. Almost every public API applies some form of rate limiting, whether the caller notices it or not.

Unlike a hard outage, rate limiting is a deliberate, visible boundary: a well-designed API tells the caller exactly how many requests remain and when the limit resets, so legitimate integrations can back off and retry instead of failing silently. It also shows up outside pure software APIs: a contact form that blocks a visitor after ten submissions in a minute, or a search box that pauses autocomplete calls while the user is still typing, are both applying the same principle at a smaller scale.

A rate limiter tracks a counter per client key (often an API token or IP address) and compares it against a threshold before letting a request through. A typical HTTP response once the limit is hit looks like this:

HTTP/1.1 429 Too Many Requests
Retry-After: 30
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1758880000

The 429 status code signals that the request was valid but refused because the caller went over its quota; the accompanying headers tell the client how many requests it gets, how many are left, and when it can try again. A well-behaved client reads these headers and paces itself instead of hammering the endpoint immediately after being blocked. Rate limiting can be enforced at several layers at once: at the CDN or reverse proxy in front of the whole platform, at an API gateway per route, and inside the application itself for expensive operations such as file exports or bulk imports.

• Fixed window: counts requests in fixed time blocks (e.g. per minute); simple, but allows a burst right at the boundary between two windows.
• Sliding window: recalculates the count over a rolling time frame, smoothing out the boundary-burst issue of a fixed window.
• Token bucket: a bucket refills with tokens at a steady rate; each request consumes a token, and bursts are allowed as long as tokens are available.
• Leaky bucket: requests queue up and are processed at a constant rate, smoothing out bursts entirely rather than allowing them.

The choice between these algorithms is mostly a trade-off between implementation simplicity and how tolerant the system needs to be of short bursts: a token bucket suits APIs that expect occasional spikes from legitimate batch jobs, while a leaky bucket suits systems that must guarantee a strictly constant downstream processing rate, such as a payment queue.

• Rate limit by a meaningful key (API token or authenticated user) rather than raw IP alone, since many legitimate users can share one IP behind a corporate network or mobile carrier.
• Return clear 429 responses with Retry-After headers instead of a generic error, so client applications can implement exponential backoff automatically.
• Set different limits per endpoint: a login route or a search box needs a tighter limit than a static asset request, since brute-force and scraping attempts concentrate there.
• Avoid setting limits so aggressively that they break normal usage during traffic spikes from legitimate campaigns, launches, or press coverage; monitor and adjust based on real traffic patterns.

Without rate limiting, a single script or a coordinated attack can exhaust server resources, drive up infrastructure costs, and degrade the experience for every other user, in what is effectively a self-inflicted denial-of-service situation. Rate limiting is also a first line of defense against credential-stuffing attacks on login forms and against scrapers copying entire product catalogs or content libraries. On the infrastructure side, predictable request volumes make capacity planning and cost forecasting far more reliable, which matters as much for a small SaaS API as it does for a high-traffic e-commerce checkout during a seasonal sale.

When we build custom APIs, integrations, or automation pipelines for clients, we configure rate limiting from day one, at the API gateway or application layer, so a traffic spike or a misconfigured integration never takes an entire system down. We size limits around real usage patterns rather than arbitrary defaults, and we surface clear error messages and retry guidance to integration partners, so a legitimate spike in usage gets throttled gracefully instead of breaking a client relationship. See our web apps service for how we design and secure these back-end systems.