Blunt and Present Beats Clever and Absent
A rate limiter doesn't need to know who you are. It needs to know how many times you've asked, and that's the whole trick.
Most abuse-defense discussions treat rate limiting as a downstream cousin of detection: first classify the traffic, then throttle the bad kind. That gets the order backwards. A limiter doesn't classify anything. It changes the attacker's cost function and lets their own math do the rest.
Abuse, almost all of it, is a volume business. Credential stuffing needs to run a leaked password list against a login endpoint before the list goes stale. Scalping bots need to clear a ticket drop in the first minute, not the first hour. Comment spam needs to post before a moderator scrolls past. Scraping needs to pull a catalog before the site notices and blocks the range. None of these strategies require staying hidden forever. They require getting enough attempts through before the opportunity closes. Stealth is a convenience. Throughput is the business model.
That's why a limiter doesn't have to be smart to work. It has to be present. Add fifty milliseconds of friction and a hard cap per key per minute, and you haven't identified a single bad actor. You've changed what the good strategy costs. A thousand attempts that used to be free now take an hour to run, and an hour is often the whole window. The attacker doesn't need to be caught. They need to be unprofitable, and a dumb quota does that without ever asking who's on the other end.
Compare that to the detection-based version: a classifier scoring requests on behavior, device fingerprint, request shape, whatever signals the model was trained on. When it works, it's precise. It can tell a real user's burst from a bot's burst and let the real one through. But it works by exception. It has a cold start for new IPs, a blind spot for behavior it hasn't seen, a training set that drifts out from under it every time attackers change their tooling, which is often. And because the traffic on the other side is automated, a gap in coverage isn't a small leak. It's an open door that gets found immediately and pushed through completely. The attacker doesn't average their luck across a thousand attempts hoping some get through undetected. They find the one hour the classifier missed a pattern, and run the whole batch through it while it's open.
That's the asymmetry that actually decides this. A detection system has to be right nearly all the time to hold, because automated traffic samples every window looking for the one where it isn't. A quota-based limiter doesn't have that failure mode, because it isn't classifying anything to get wrong. It doesn't have a seam to find. Every request costs the same regardless of who sent it, so there's no gap for automation to locate and exploit at scale. The limiter's dumbness is exactly what makes it hard to game: there's nothing there to fool, only a counter to hit.
The cost of that reliability is real, and it lands on legitimate high-volume users too: the researcher hitting an API in a tight loop, the business running a batch job at 2am, the power user who wants everything at once. Blunt limiting doesn't distinguish them from an attacker any better than it distinguishes a spammer from a fan posting fast. That's the actual tradeoff: reliability against precision. It's worth paying, because the failure mode on the other side is worse. A precise system that's occasionally absent gives its entire capacity away in the hour it's absent. A blunt system that's always on gives away nothing, ever, to anyone.
Sophistication is a feature, and features can regress: drift, a bad deploy, a config rollback. Presence has no version number. It's either on or it's not. Bet on the one that can't have a bad day.