LEARN
What rate limits actually protect
A rate limit caps how fast one client can call something. It does not protect your budget, your data or your business rules. Here is the difference.
In short.
A rate limit caps how often one client can call something in a window. It does not protect your budget, your data or your business rules. A hundred calls a minute is still a hundred calls a minute you paid for.
What a rate limit does
It counts requests per client per window. When the count goes over the limit, the request is refused. That is the whole mechanism.
It is genuinely useful. It keeps one misbehaving script from taking the whole service down, it protects a shared endpoint from a burst, and it gives you a number you can alert on. It is also the cheapest control to add, which is exactly why it is the first one people reach for.
What it does not do
| Concern | Does a rate limit handle it? |
|---|---|
| Server overload | Yes. This is what it is for. |
| One account running away | Partly. Only while the count stays under the limit. |
| Your monthly bill | No. The limit is a count, not a cost. |
| Somebody else's data | No. Nothing about who is asking. |
| Business rules | No. A limit does not know what a refund is. |
| Many accounts | Not on its own. A limit per account is a limit per account. |
The distinction that matters
Request rate is not cost rate. If one request costs a fraction of a cent and the next one costs a euro because the caller asked for a million rows, then both requests count as one against your limit.
There is a third number as well: concurrency. How many expensive operations are running at the same moment. A limit of a hundred a minute lets all hundred run at once if they arrive together. That is what takes a service down, and a request limit does not see it.
Where rate limits break
- Only per account. One limit per account means a hundred accounts get a hundred times the allowance. Free signups make that cheap for an attacker.
- Only per IP. Shared addresses break it, and so do botnets and address rotation.
- A fixed window with a burst at the edge. If the window resets every minute, a client can send the full allowance twice within two seconds, right across the boundary.
- No expectation about backoff. A limit that refuses politely and instantly invites a tighter loop. Refuse slower, or refuse with a header that says when to come back.
- Counting the wrong thing. Counting requests when what you need to count is cost, or rows, or minutes of expensive work.
What to layer on top
- A rate limit on the endpoint, so a single client cannot flood it.
- A concurrency cap on the expensive operation, so the service stays responsive when everybody arrives at once.
- A spend or quota limit on the account, counted in the thing you pay for.
- An alarm on the daily total per account, and on spend against revenue.
- A hard ceiling inside a single request, so one request cannot be expensive on its own. This is the part people skip, and it is the part that stops the worst case.
Pick the number from your own traffic
The number everybody copies is wrong for you. Look at what your real peak looks like, put the limit comfortably above it, then watch what happens when a client sits at the limit. If nobody ever touches it, it is too high. If your normal users hit it, it is too low.
And when you do find the bill that does not match your users, the shape of the problem is nearly always the same. It is covered in how users can run up your API bill.