Why you shouldn’t use Redis as a rate limiter: Part 1 of 2
A tour of the common Redis-based rate limiter implementations — and the correctness and performance traps each one hides.
We can't find the internet
Attempting to reconnect
Something went wrong!
Hang in there while we get back on track
Rate limiting and admission checks that help reduce overload and protect expensive work.
Set admission budgets for launch spikes and promos before excess work reaches your handlers.
Fewer moving parts to run and monitor. Spend less on Redis and ops.
Add via SDK. Keep your stack. Clear limits your customers understand.
UNDERSTAND OVERLOAD · KEEP USEFUL WORK MOVING
For developers, architects, and managers: 27 narrated lessons on why services overload and how to protect them. No cloud experience required. Start with one request, or jump to any lesson.
Four chapters, one learning path. Read or listen in any order. ~41 minutes total · Times shown at 1×.
Keep enough capacity to finish work and recover.
Contain one customer's excess without punishing everyone.
Reduce work entering a shared dependency when it slows.
Choose, combine, and test the right protections.
Read the explanation or use the course map above. Audio is optional.
Independent histories and feedback delay
A serverless function may reuse an environment.
Not automatically a shared observation record.
Possible failure pattern, not measured traffic or a stability prediction. A/B/C keep separate local histories. Later results return to their originating environment; shared scope is introduced separately.
Read the numbered steps in order. The explanation below follows the narration.
Separate environments have separate memories.
Local histories can synchronize a burst–refuse–reopen cycle; shared observations reduce fragmentation.
Local histories can synchronize a burst–refuse–reopen cycle; shared observations reduce fragmentation.
A serverless execution environment can sometimes retain local state between requests. Keeping latency history there seems convenient: no additional service to run. But each environment knows only its own past, and a new one may know nothing.
Suppose many environments still remember fast work. They admit a burst into the same database. Slow results arrive only after that work finishes. This is feedback delay: decisions happen before the consequences become visible.
Those environments can then refuse work together. Few fresh results arrive while they refuse. Their old observations expire, and optimistic empty histories can let many environments reopen together. Another burst reaches the database. Repeated opening and refusing is an oscillation: the system swings instead of settling. This is a possible failure pattern, not a claim that every local controller behaves this way.
A shared tracker lets these clients contribute to and read the same intended observation scope. It reduces fragmented histories without operating a separate history store in each service. Sharing does not remove feedback delay or guarantee stability. Freshness, bounded work, and careful recovery remain important.
Each labeled box is a separate execution environment. A reused environment can sometimes retain local history between requests, but those local records are not automatically shared with the other environments.
C illustrates a new environment with an empty history while A and B have their own past observations. Missing measurements do not establish that the shared database is healthy or has spare capacity.
For the following possible failure pattern, consider environments whose histories retain old fast observations. Their earlier experience is evidence about the past, not a direct measurement of the shared database’s current pressure.
Follow the three work routes into the same database. A, B, and C still have old fast evidence when admitting this burst; slow results from the newly admitted work have not returned yet.
Each returned result can update its originating environment’s local history. That result is delayed feedback about work already admitted; whether it changes the guard’s signal depends on eligibility and history rules.
The new evidence comes from an operation admitted earlier. A client cannot use that operation’s final duration before the measurement finishes. Sharing evidence later does not remove this causal delay.
Here the eligible histories cause the local guards to refuse new protected work. No new work routes reach the database. This is a possible branch, not a claim that every slow observation necessarily trips every guard.
While these clients skip protected work, they produce few new completions to measure. Existing work may still return results, but a refusal itself is not a new database latency observation.
The old observations stop qualifying under the history rules. That leaves too little current evidence in this illustrative branch. A history aging out does not itself make the database faster or add processing capacity.
Follow the work routes returning together: the histories are empty, not freshly measured fast. Optimistic reopening can admit another combined burst before useful current evidence has accumulated.
Each row is one environment and each column is a stage, not a measured time interval. The matching shapes show a possible synchronized pattern: a burst, common refusal, and another burst instead of settling.
The arrows now represent reports and admission checks, not database query traffic. A, B, and C contribute to and consult the same intended shared observation scope; they no longer rely only on their separate private past.
Sharing reduces fragmented histories but does not guarantee stable control or remove delayed feedback. Freshness rules, bounded work, and careful recovery remain necessary; there is deliberately no promised flat healthy throughput line here.
Content revision: 07c7dd00db17
Download review copy (27 lessons)All environments stopped sending work. Why might they reopen into another burst?
While refusing, they may receive few fresh completions. Expired local histories can trigger optimistic reopening at similar times.
Use a shared, consistently scoped tracker across execution environments; test stale samples, new environments, expiry, and coordinated reopening.
Shared history helps but does not guarantee stable feedback, eliminate delay, or automatically make independent server state global.
Start here. No earlier lesson is required.
Serverless and autoscaling change how compute is supplied, not whether resources are finite.
The eligible recent minimum is a pressure signal with freshness and missing-data limits.
The closed loop includes admission, work completion, reporting, retention, and recovery. Test the whole loop under rapid changes, not only steady overload.
Original explanation inspired by Fred Hébert and operational references; no endorsement implied.
AI-generated narration: ElevenLabs Eleven v3, Daniel stock voice. Audio streams only when you start listening.
A tour of the common Redis-based rate limiter implementations — and the correctness and performance traps each one hides.
The myth of infinite serverless scale — why adding machines doesn’t fix overload, and what to do instead.