Rate limiting: protect the API

Why limit requests at all

Three reasons to cap how often a client can call your API: abuse (someone scripting login attempts or scraping every walker profile), cost (every request burns CPU, DB connections, maybe a paid third-party call), and fairness (one noisy client shouldn't starve everyone else's requests of capacity). Rate limiting turns "unbounded" into "bounded and predictable."

Fixed-window counting is the simplest approach: pick a window (say, 60 seconds), count requests in that window, reject once the count passes a limit, reset the counter when the window rolls over. It's cheap and easy to reason about — but it has a real flaw at the boundary: a client can send the full limit in the last second of one window, then immediately send the full limit again in the first second of the next window. Two limits' worth of requests land in under two seconds, right at the seam. Sliding-window approaches (tracking a rolling timestamp log, or a weighted blend of the current and previous window) smooth that out, at the cost of more bookkeeping. Fixed-window is the right default when "roughly N per minute" is good enough — which it usually is.