Rate limiting saved us after a bot flood last Tuesday

We run a small e-commerce API for our shop and last Tuesday a scraping bot hammered our endpoints about 30,000 times in an hour. I thought our WAF would catch it but it didn't even flinch. Digging into the logs I realized we never set a proper rate limit on the product search route. I added a simple token bucket with a 100 requests per minute cap per IP and suddenly the server load dropped by 80 percent. It was such a basic fix but I'd been ignoring it for months. Now I'm wondering how many other small teams have the same blind spot. Has anyone else got burned by a missing rate limit on an endpoint you thought was low risk?

1 comments

Log in to join the discussion

Log In

1 Comment

oliver_hunt18d ago

Man, I used to think rate limiting was just something you set up for public APIs and forgot about, but this totally proves even your "boring" routes need it. I had a similar wake-up call when a webhook endpoint I ignored started getting hammered by a misconfigured client, and it choked our whole DB. It is wild how one tiny rule change can save you from a whole weekend of chaos, right?

2