The Stampede

High-value endpoints like login, signup, password reset, and checkout are magnets for automated abuse. Credential stuffing, card testing, and scraping arrive in bursts that look nothing like a human pace. The origin tries to serve all of it, and both the bill and the latency climb.

Teams often notice only when the database is on fire or the fraud team escalates. By then the flood has already been served.

Most applications make the rate-limit decision deep inside their own code, after the request has already reached origin and started doing expensive work. Adding a good limiter usually means new infrastructure and shared state that nobody wants to own, so it gets deferred.

Cloudflare runs in front of the origin, so the throttle happens at the edge before any compute. The first few requests in a window pass, and the rest get a 429 immediately. The origin only ever sees traffic that is within the limit.

Rate limiting is one layer, not the whole defense. Per-IP limits get paired with Turnstile and bot management for distributed attacks. As a first gate, though, it removes the cheapest and loudest abuse for almost no cost.

The site runs on Cloudflare Pages, where the native Rate Limiting binding is not available, so the demo uses a D1 sliding-window limiter instead: one row per request, a count over the trailing window, and a 429 when the count exceeds the limit. Same observable behavior, different mechanism.

Knowing that edge, which surface gives you which tool, is part of the SE job. The demo lets you hammer the gate and watch the herd get turned back at five requests per ten seconds.