One client starts hammering your API, and everyone else pays for it. Your server burns its capacity on one noisy caller while normal requests queue behind it and start timing out — and from the outside it looks like your whole service is broken.
Rate limiting fixes the fairness problem by counting requests per client, per time window.
A rule looks like this:
100 requests / minute / API key
Three things matter in that line, and all three are the point:
→ a NUMBER
→ a WINDOW it applies over
→ an IDENTITY it's counted against
That identity is what makes it work. Without it you're limiting "everyone" and you've just built a slower API for your good users.
WHAT HAPPENS AT THE EDGE
Under the limit, requests pass through and get their normal 200.
Over it, the excess gets HTTP 429 Too Many Requests — ideally with a Retry-After header, so a well-written client knows when to come back instead of retrying immediately and making things worse.
The 100/minute above is an illustration, not advice. The right numbers depend on what your endpoints actually cost, who your clients are, and what your infrastructure can absorb. A search endpoint and a login endpoint shouldn't share a limit.
TWO THINGS IT IS NOT
✘ It is not a denial-of-service defence. Per-identity limits work because the traffic has an identity. A distributed flood arrives from thousands of addresses, each staying politely under your threshold. That's a job for upstream filtering, not your application.
✘ It is not authentication. Rate limiting counts; it doesn't verify. It sits alongside authentication, authorization and input validation — never in place of them.
—
#Astmation — #software #systems, #automation, and #AI-powered #applications.
Build. Automate. Evolve.
https://astmation.com/
Watch on YouTube