Rate limiting is a control that caps how many requests someone can send to your service in a given window of time, say 100 calls per minute. Once they cross the limit, further requests are politely refused until the window resets. It protects a system from being overwhelmed, whether by accident or on purpose.
A good analogy is a busy nightclub with a doorman counting people in. The venue can hold a certain number safely, so once it is full the doorman pauses entry and lets people through as others leave. Rate limiting does the same for software: it keeps the load inside what the system can handle, so one greedy client cannot ruin the experience for everyone else. This matters most for an API, where a single misbehaving integration could otherwise fire thousands of requests a second.
It is also a frontline defence against abuse, slowing down brute-force login attempts and softening the impact of a DDoS attack, though it works best alongside other protections rather than alone.
The hard part is picking the number. Set the limit too low and you block legitimate power users or a mobile app that legitimately syncs in bursts. Set it too high and it stops almost nothing. The usual answer is layered limits, often enforced at an API gateway: a gentle per-user cap, a stricter one on sensitive endpoints like login, and a wider one for the whole service. Good limits also return a clear retry header, so honest clients can back off instead of guessing.
At TopDevs we add sensible rate limits to every API and login endpoint we build, so client systems stay responsive under pressure and resist the most common forms of automated abuse.
