Rate limiting: why a site says "too many requests

Rate limiting means setting a maximum number of requests that a visitor, an account or a program can send in a given time. Beyond it, the site answers "too many requests" and asks you to wait. It is not a breakdown: it is a protection.

The analogy: the nightclub door

A bouncer lets people in a few at a time. It is not to annoy those waiting: if everyone rushed in at once, the room could not work anymore. Rate limiting is that bouncer, standing in front of your application.

What it protects

• Passwords. Without a limit, someone can try thousands of combinations on a login page. With a limit, they are stopped after a few attempts. It complements password hashing, which protects what is stored, whereas rate limiting protects the front door.
• The server. A badly written program, an impatient user or an attack sending a flood of requests can saturate the application and slow it down for everyone.
• Costs. Every request has a cost, and some, like those calling a pay-per-use service, can add up fast.
• Fairness. One heavy user must not take all the room from the others.

How it works

The application counts the requests received during a period, for example per minute, for one identity: an IP address, an account, an access key. When the counter exceeds the limit, the following requests are refused. The refusal usually carries the code 429 ("Too Many Requests"), sometimes with a hint of how long to wait. When the period ends, the counter starts again from zero.

Limits vary by place: stricter on login or password reset, wider on simple page reads.

What can go wrong

• A limit that is too low blocks real users. Several people can share the same address (an office, a school): limiting by address only sometimes punishes them all together.
• No limit at all leaves the door open.
• A badly handled response: if your own application calls an API that answers 429, it must wait and retry calmly, not keep insisting at full speed. A queue is a good way to space out those calls.

Key takeaway

Rate limiting caps the number of requests per identity and per period. It protects logins, the server and costs, provided you choose limits suited to each use.

And for your product?

An application with no limit on its login page or on its most expensive endpoints is a common oversight, especially in quickly generated code. A code audit of your app shows where limits are missing. We can talk about it in a 30-minute call.