Post

1/ Ever watched your servers start sweating because a single rogue bot or a buggy client retry loop went wild and hammered your API with hundreds of requests per second? That’s rate limiting in action – the invisible guardrail that keeps your system alive, fair, and costs in check.

2/ There are exactly 5 algorithms you must know. I’ll give you the mental model, when to pick each, and the real trade-offs (the stuff interviewers actually test).

3/ 1. Token Bucket Tokens refill at a steady rate into a bucket. Each request grabs one. Run out? Block or queue. Superpower: Allows natural bursts (uploading 20 photos at once feels smooth). Real-world: Stripe, GitHub, AWS APIs. Pick this when your users are humans, not robots.

4/ 2. Leaky Bucket Requests pour in but only “leak out” to your servers at a fixed constant rate. Bucket fills up? Extra requests get dropped. Superpower: Perfectly smooth downstream traffic – your DB never sees spikes. Catch: Zero bursts allowed. Use when stability > flexibility.

0 reposts0 likes

5/ 3. Fixed Window Time sliced into rigid blocks (every 60 seconds). Count inside the block, reset sharp at the boundary. Superpower: Dead simple, almost zero memory. Big catch: Everyone games it – spam at 11:59 + 12:01 and you sneak double the limit.

6/ 4. Sliding Window Log Store a timestamp for every single req. On new req, drop anything older than the window & count the rest. Superpower: Most accurate – no boundary tricks possible. Catch: Memory explodes at scale (millions of timestamps = pain) Only when absolute fairness is non-negotiable.

7/ 5. Sliding Window Counter (Big Tech’s default) Hybrid genius. Keep counters for previous + current window + smart weighted math. Example: 100 req/min limit, 30s into the minute. Previous window: 80 Current: 20 Weighted = (80 × 0.5) + 20 = 60 → still under limit.