Rate limits, explained: the guardrail every vibe coder forgets

Without a limit, one script can hit your app a million times a minute. Your bill, or your server, won't survive it.

A rate limit caps how many requests someone can make in a window of time, so no single user, or bot, can swamp your app.

Wikipedia: "rate limiting is used to control the rate of requests sent or received." It "can be used to prevent DoS attacks and limit web scraping." A cap per minute, per user or per address.

Every public app needs one, because without it a bug or a bot can hammer an endpoint endlessly. On metered services (AI calls, databases) that's a runaway bill; on any service, it's an outage as the flood crowds everyone else out.

This is a signature vibe-coder miss. In the Moltbook lesson, a security analysis found that "Anyone could register millions of agents with a simple loop and no rate limiting" A public form with no limit is an open door, for abuse and for cost.

We see the other half daily: this site is hit constantly by aggressive crawlers, and controlling how often requests are allowed is part of keeping it up. A rate limit protects you from bots, from your own runaway code, and from one heavy user ruining everyone else's speed.

Try it with the rules off. In the sandbox on launch day, turn the rate limit off and watch errors and cost spike as traffic surges. Then turn it on and watch the flood get capped to something the app can survive.