Rate limiting strategies that actually scale

Rate limiting is deceptively simple. A naive counter-per-minute works in your test suite and breaks in production the first time a user opens ten tabs at once.

Sliding window vs fixed window#

A fixed window resets on the hour. That lets a single client burn their entire quota at 11:59 and then do it again at 12:00 — an effective 2x limit. Sliding windows smooth this by weighting the previous window's count against the current.

Redis as the source of truth#

In-memory counters break the moment you run more than one server instance. Redis INCR with EXPIRE gives you an atomic counter across your entire fleet, costs a single round trip, and handles the "first hit" race correctly.

Token buckets for burst tolerance#

Humans don't browse at a steady rate. Token buckets let users "save up" unused capacity and spend it in bursts — which matches real behavior better than strict windowed quotas. Implemented in Redis with Lua scripts to keep the refill atomic.

Fail open or closed?#

When Redis is down, the safe default is usually to fail open on user-facing traffic (allow requests through with a log) and fail closed on sensitive operations (payment mutations, password resets).

Measure before you tune#

Before setting limits, measure the p95 request rate of your top 1% of users. Your first draft should sit comfortably above that number.