Rate limiting and protecting your system
A rate limiter caps how often each client may call you, so one buggy app, one scraper or one attacker cannot use up the capacity everyone else needs. This lesson explains the main algorithms, where to put limits, and how to build one that works across many servers.
By the end you can
- Explain fixed window, sliding window, token bucket and leaky bucket, and the weakness of each
- Choose the key to limit by: IP, user, API key or store
- Return
429 Too Many Requestswith a usefulRetry-After - Configure Nginx
limit_reqand@nestjs/throttlerwith per-route limits - Write an atomic Redis token bucket in Lua and call it from ioredis
The everyday picture
On the last evening before a big festival, a crowd waits outside a grocery store. If the doors open with no control, two hundred people rush in at once. The aisles jam, nobody can reach the shelves, the cashiers cannot see their queues, and shoppers who are already inside cannot get out. Everyone has a worse time, including the people who got in first.
So a guard stands at the door and lets people in at a steady pace, say ten a minute. When a family of four arrives together, he lets them all in, because the floor can absorb a small group. When the crowd is too big, he tells new arrivals plainly, "about fifteen minutes", so they can come back instead of pushing. That guard is a rate limiter: a steady rate, a small allowance for bursts, and a clear message about when to try again.
Why limit at all
A rate limit caps how many requests one client may make in a period. You need one for four reasons:
- Abuse. Password guessing on
/auth/login, OTP spam, and scrapers copying your catalogue and prices. - Fairness. One partner shop's app with a retry loop bug should not slow down the other 1,800 shops.
- Protecting shared parts. The database has a fixed capacity (Scaling up vs scaling out). A limit keeps one client's report exports from using all of it.
- Cost. Every OTP SMS and every call to a paid API costs money. An attacker who can trigger unlimited SMS can run up a real bill overnight.
Quick check
Your servers are nearly idle tonight. Which endpoint still needs a strict limit?
Each OTP request costs real money and can be used to flood someone's phone, whatever the server load. Product reads are cheap and cacheable. The health check should never be limited, or the load balancer may remove healthy servers.