Every publicly reachable application is eventually confronted with more requests than it should process: through attacks, faulty integrations, overeager scripts or simply success. Rate limiting defines how much is too much.
What it is for
Against brute-force attacks on sign-in and password reset. Against mass extraction of data through APIs. Against overload that affects all users. And increasingly against cost: an AI feature without limits can generate substantial bills in a short time, because every call costs tokens.
Algorithms
A fixed window counts requests per fixed time window — simple, but prone to spikes at the window boundary. A sliding window smooths this effect. A token bucket refills a credit at a fixed rate and allows short bursts up to the bucket size, which often comes closest to actual usage. For most applications the choice matters less than consistent application in the right places.
Limits per key
What a limit applies to determines its effect. Per IP address protects against anonymous attacks but hits users behind the same corporate IP together. Per user or API key is fairer for signed-in use. Per tenant fits quotas by plan. Often a combination is needed: a coarse limit at the edge of the infrastructure and finer limits in the application.
The response to the client
Exceeded limits are answered with HTTP status 429 Too Many Requests, ideally with a Retry-After header stating when requests may resume. For API customers, headers showing the remaining quota help. Clients should respond to 429 with exponential backoff rather than immediate retries.
Where it belongs
At least on sign-in, registration, password reset, public APIs, forms and expensive features such as AI calls, exports and reports. Rate limiting therefore belongs in every pre-launch SaaS security checklist and in LLM feature production readiness.