Rate limiting explained: what it protects and what it breaks

It counts requests against something and refuses them past a threshold. That is the whole mechanism, and its simplicity is misleading, because a limit does not distinguish between traffic you wanted to stop and traffic that merely resembles it.

This makes rate limiting different from every other filtering decision on this site. A rule that matches malformed input refuses something that was already wrong. A rate limit refuses requests that are individually perfectly valid, on the grounds that there have been too many of them, and «too many» is a judgement you made in advance about circumstances you had not seen yet.

Every limit answers these, whether deliberately or by accident.

What is counted. Requests are the obvious unit and often the wrong one, because they differ enormously in what they cost you to answer. A hundred cached pages and a hundred searches are the same number and not remotely the same load.

Against what subject. An address, an account, a credential, or the domain as a whole. This choice decides who suffers when the limit is wrong, and it is the decision people give least thought to.

Over what window. A minute, an hour, a day, and whether the count resets abruptly or slides. The window shapes what ordinary use looks like to the counter.

What happens at the threshold. Refusal, delay, or a reduced response. These are not interchangeable, and the difference decides whether a misjudged limit costs you a complaint or a customer.

The most common subject is the least reliable one, and the reason is structural rather than technical.

A single address routinely carries an entire office, a mobile network's users, a school, or a university. Limiting by address means those people share a budget none of them knows about, and the busiest of them exhausts it for everybody else. Meanwhile anything with a reason to avoid the limit moves between addresses freely, because addresses are cheap and plentiful to whoever is deliberately spreading traffic.

The result is a control that constrains your customers reliably and its intended target barely. Where identity is available, counting against a credential or an account is both fairer and harder to evade, and where it is not, the limit should be set expecting the sharing.

Real traffic is not evenly spaced, and a limit that assumes it is refuses people behaving normally.

A page load fetches many things at once. A person returning after lunch opens six tabs. An integration wakes on a schedule and does its work in a burst, then sleeps. Each is ordinary, and each looks identical to a counter watching a narrow window. A limit tight enough to catch abuse in that window is tight enough to catch all three.

The usual answer is to allow a short burst above the sustained rate, which matches how genuine clients behave without raising the long-run ceiling.

A refusal that explains itself is answered correctly; a refusal that does not is retried immediately.

The status code exists to say that the limit, rather than the request, is the problem, and a well-behaved client treats it differently from an error. Alongside it, telling the client when to come back is what turns a retry storm into a pause. Without that, a client with nothing to go on assumes the fastest reasonable thing, which is to try again at once, and the refusals you are issuing become load of their own.

Three steps, in order, and the first is the one that gets skipped.

1. Watch before enforcing. Record what the limit would have refused against real traffic for long enough to include a quiet day and a busy one. This is the same argument the whole filtering layer rests on, and it applies more sharply here because the traffic being refused is valid.
2. List your own automation first. Monitoring, deployment tooling, partner integrations, and scheduled jobs all look like abuse to a counter. Exempting them by credential rather than by address is what keeps the exemption working after infrastructure changes.
3. Decide what a wrong decision costs. If refusing a genuine customer is expensive and missing some abuse is not, the limit belongs looser than instinct suggests, and the response belongs gentler than refusal.

The pages below take each decision apart: the counting algorithms and how they differ in behaviour rather than in name, the status codes a blocked client actually sees, limits set per endpoint according to what each costs, the choice between address, account and credential, bursts and smoothing, telling a client when to return, which state to expose in headers and which to withhold, exempting your own automation safely, testing a limit without taking down your own service, what to watch after enforcing, and why counters on separate nodes disagree.

Bridge WAF applies rate limiting per domain, which is the unit limits are defined and counted against. That granularity is worth checking against your expectations before planning around it, since the subject of the count decides what a limit can and cannot express. Requests are inspected at the edge, so traffic that exceeds a limit is refused before reaching your origin rather than after. See what the platform offers at Bridge CDN.