Rate limiting: stop abuse without blocking customers

What it actually does

Every visitor makes requests. A rate limit says: from one client, I will accept this many in this many seconds, and anything beyond that gets refused. That is the whole idea — it is a counter with a consequence.

What makes it valuable is the asymmetry. A scraper, a credential-stuffing script or a runaway integration all look identical to a browser at the level of a single request; you cannot tell them apart by inspecting one. But they behave completely differently over time: a human reads a page and clicks a few links a minute, while a script makes hundreds. Rate limiting catches behaviour rather than content, which is why it stops attacks that no signature would recognise.

Choosing a number that does not hurt

The mistake is picking a limit from intuition. Start from what your real traffic already does: look at your busiest legitimate visitor over a normal hour, then set the limit comfortably above it. A limit that only a bot could hit is doing its job invisibly; a limit that a keen customer can trip is a support ticket you created yourself.

Two details save you from most false positives. First, remember that several people can share one address — an office, a school, a mobile carrier's NAT — so a limit calibrated to "one human" will punish a building. Second, remember your own traffic: monitoring, health checks, a partner integration and your CI all come from few addresses at high frequency, and they are the first legitimate clients a new limit tends to break.

Start deliberately loose. A limit you tighten after a week of watching is far cheaper than one you loosen after a customer complains.

Not every path deserves the same limit

A single site-wide number is a compromise nobody is happy with — loose enough for browsing means useless on a login form, tight enough for login means a broken product page.

Think in terms of what a request costs you and what abusing it wins the attacker. Login, password reset and checkout endpoints are cheap to request and valuable to attack, so they take the strictest limits — a person signs in once, not forty times a minute. Search and API endpoints are expensive to serve and attractive to scrape: limit them by what a real integration needs. Ordinary pages and static assets are cheap and heavily used by real people, so they need generous limits or none at all, because the CDN cache is already absorbing them.

On cdn.com.tr the request rate limit can be set account-wide and also per delivery rule, which is what makes this practical: a strict rule matching your login path, a looser one for the rest of the site.

Why the edge is the right place for it

Rate limiting inside your application works, in the sense that the code runs. But by the time your app can count a request, it has already accepted the connection, occupied a worker and probably touched the database — the attack has already cost you the resource you were trying to protect. Under a flood, the limiter itself becomes part of what falls over.

Enforced at the edge, the refusal happens near the client, before the traffic reaches your origin at all. Your server never sees it, so the cost is not yours. That is also why edge rate limiting keeps working when your origin is already struggling: the limit is not competing for the resources it is defending.

Rate limiting vs WAF vs DDoS protection

These three get used interchangeably and do genuinely different jobs.

Rate limiting counts. It knows how often a client is asking, and nothing about what it is asking for. It stops brute force, scraping and accidental hammering.

A WAF inspects. It reads the request and blocks the ones that look like SQL injection, cross-site scripting or a known exploit — a single malicious request is caught on its first attempt, no matter how slowly it arrives.

DDoS protection absorbs. When the traffic is large enough that merely counting it would overwhelm you, the volume has to be soaked up by network capacity spread across many locations.

You need all three because each covers the others' blind spot: one clever request that a counter would wave through, one thousand innocent-looking requests a WAF sees nothing wrong with, and one million requests that no single machine can even evaluate. On cdn.com.tr they are part of the same edge, configured from one panel.

Rolling it out without breaking anything

Set the limit high enough that you expect it never to trigger, then watch. Look at what actually got refused: if it is a scraper or a login script, tighten with confidence; if it is your own monitoring or a customer's integration, you just learned something before it cost you a complaint.

Keep exceptions honest and few — your monitoring and known partner integrations, not "whatever complained loudest". And treat a limit as a living number: traffic grows, a mobile app ships, an integration doubles its polling. A limit that was generous last year can quietly become the reason a feature feels broken.