Rate limiting your application
A single visitor who sends ten thousand requests a minute is not a visitor — they are a problem. Rate limiting is how your application tells the difference between use and abuse, and keeps the one from starving the other.
Without a limit, one client can consume everything — hammering a login, scraping an API, or simply misbehaving — and legitimate users get nothing. Rate limiting caps how fast any one source can make requests, so no single client can starve the rest. It is basic hygiene for anything public.
Where it matters most
- Login endpoints — the first defence against credential brute-force; see fail2ban
- APIs — so one client cannot monopolise or scrape them
- Expensive operations — search, export, anything that costs real work per call
Two layers, two jobs
The proxy in front can rate-limit cheaply by IP — see a reverse proxy in front — stopping floods before they reach your code. The application can limit more intelligently, per user or per API key, because it knows who is asking. Use both: the proxy for crude volume, the app for fairness.
Per-IP has limits
Limiting by IP is simple but blunt: many real users behind one office or mobile network share an IP, so too tight a per-IP limit punishes them, while an attacker spread across many IPs slips under it. For anything tied to accounts, limit per user or per key as well — it is fairer and harder to evade.
Fail politely
When a client hits the limit, return 429 Too Many Requests with a Retry-After header, not a generic error or a dropped connection. A well-behaved client backs off and retries; a badly-coded one at least gets a clear signal. Silent failures just generate confused retries that make the load worse.
Do not lock out the innocent
A rate limit that is too aggressive becomes its own outage — real users bouncing off 429s. Set limits well above normal usage, watch what legitimate traffic actually looks like first — see understanding your traffic — and tighten only as far as you need. The goal is to stop abuse, not to ration normal use.
It pairs with banning
Rate limiting slows a bad client down; fail2ban removes one that keeps trying anyway. Together they are the standard answer to brute-force and scraping: throttle first, ban the persistent offenders.
Still stuck? Mail support@novogara.com — an engineer answers, at any hour. Back to the knowledge base