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
Keep your API fast—even at peak
Rate limiting and admission checks that help reduce overload and protect expensive work.
Reliable at peak
Set admission budgets for launch spikes and promos before excess work reaches your handlers.
Lower cloud costs
Fewer moving parts to run and monitor. Spend less on Redis and ops.
Dev‑first adoption
Add via SDK. Keep your stack. Clear limits your customers understand.
UNDERSTAND OVERLOAD · KEEP USEFUL WORK MOVING
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.
27 lessons · automatically continues
Course map Lesson 16 of 27 Browse all lessons
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.
- 01 A useful result starts with one request You are here
- 02 Unfinished work grows when arrivals outrun completions You are here
- 03 More waiting space does not make work finish faster You are here
- 04 A timeout ends waiting, not necessarily the work You are here
- 05 Retained work can exhaust a process’s memory You are here
- 06 One failed copy can push its neighbors over capacity You are here
- 07 Refuse new work while the application can still recover You are here
- 08 Different compute platforms still have finite resources You are here
- 09 A shared database failure can spread back into every app You are here
- 10 Restore capacity before restoring full traffic You are here
- 11 A circuit breaker stops repeating a failing call You are here
Contain one customer's excess without punishing everyone.
- 12 One customer’s excess should not ruin another’s day You are here
- 13 A rate limit checks one customer’s recent allowance You are here
- 14 Copies and languages must share the same intended policy You are here
- 15 Fairness helps contain damage without reserving every resource You are here
- 16 A legitimate crowd can exceed shared capacity You are here
Reduce work entering a shared dependency when it slows.
- 17 Measure the operation whose pressure you want to observe You are here
- 18 A shared tracker observes; a guard decides; your app acts You are here
- 19 Even the fastest recent observations can become slow You are here
- 20 Separate local histories can reopen into the same burst You are here
- 21 Replace optional expensive work before refusing essential work You are here
- 22 A local breaker learns after calls have already piled up You are here
- 23 Fast errors explain why the protections remain complementary You are here
- 24 Latency feedback helps without measuring exact spare capacity You are here
Choose, combine, and test the right protections.
Read the explanation or use the course map above. Audio is optional.
Legitimate aggregate overload
-
Viewer A · A
One suggestion
Within allowance
-
Viewer B · B
One suggestion
Within allowance
-
Thousands more
Each within allowance
Combined demand rises
Illustrative mechanism. Highlight follows the explanation; not a benchmark.
Read the numbered steps in order. The explanation below follows the narration.
A live show brings a legitimate crowd.
All customers can behave reasonably while their combined work overloads the database.
0:00
Read transcript & diagram walkthrough
What you will learn
All customers can behave reasonably while their combined work overloads the database.
Now the service hosts a popular live show's video suggestions. A commercial break brings thousands of viewers at once. Aggregate demand means their combined demand, not what any one viewer sends.
Each viewer requests one suggestion and stays within the individual allowance. Every fairness check can pass. But all those accepted requests still reach the same database. If combined work exceeds the database's capacity, unfinished work accumulates even though nobody broke a rule.
More application copies and local memory protection can keep the application layer alive. They do not automatically increase the database's capacity. A fixed database-wide rate cap can be useful, but its safe value depends on request cost and available capacity. One simple lookup is not the same work as a large report.
This is a different problem from Orchid's bulk job. We are no longer asking which tenant exceeded an allowance. We are asking whether the shared resource can handle more work now. Passing the fairness check alone does not answer that question.
Diagram walkthrough
-
A live show brings a legitimate crowd.
A live-event spike can contain only reasonable individual requests. Aggregate demand is their combined work.
-
Every fairness check can pass while aggregate work is too high.
Every per-tenant check can pass while the shared database receives more work than it can finish.
-
Adding application copies does not add database capacity.
Application scaling and local guards do not add database capacity. A fixed aggregate cap also depends on request cost and available capacity.
-
Fairness and current shared capacity are different questions.
Fairness asks who exceeded a policy. Shared-resource admission asks whether adding work looks safe now. One answer cannot substitute for the other.
Content revision: 07c7dd00db17
Download review copy (27 lessons)Check your understanding & apply it
Every viewer is within their allowance. Can the shared database still overload?
Show the explained answer
Yes. The sum of individually reasonable use can exceed the database’s available capacity.
Integration guidance
Keep tenant fairness, but also bound and observe work sent to shared dependencies. Test changes in workload cost and available capacity.
Where the promise stops
A fixed shared-resource cap can be a useful guardrail; it is not automatically well-sized for every workload mix.
Technical depth & sources
Concepts used here
Start here. No earlier lesson is required.
-
Unfinished work grows when arrivals outrun completions
100 arrivals/s − 80 completions/s = 20 extra unfinished requests/s.
-
A shared database failure can spread back into every app
Database unavailable → calls wait or fail → unbounded retained app work can cause further failure.
-
One customer’s excess should not ruin another’s day
Contain one customer's excess before it harms other customers.
-
A rate limit checks one customer’s recent allowance
A rate limit enforces an allowance, not a measurement of current resource health.
Implementation detail
A user-count spike, costlier queries, or reduced database capacity can all make the same per-tenant policy insufficient.
Original explanation inspired by Fred Hébert and operational references; no endorsement implied.
- Fred Hébert: Queues Don’t Fix Overload
- Google SRE: Cascading failures and recovery
- Google SRE: Overload and degradation
- Linux: Memory limits and OOM
- PostgreSQL: Memory overcommit
- AWS Lambda: Environment reuse
- Microsoft: Bulkhead isolation
- MIT: Little’s law
- HTTP 503 · HTTP 429
- RateLimitly integration documentation
- Resilience4j: Circuit breakers · AWS: Shared breaker state
AI-generated narration: ElevenLabs Eleven v3, Daniel stock voice. Audio streams only when you start listening.
Why teams choose us
Happier customers
Consistent response times when it matters most.
Faster delivery
Ship features, not DIY limiters and brittle ops workarounds.
Clear controls
Per‑tenant and per‑route limits your stakeholders can reason about.
Engineering blog
View all posts →Auto-Scaling Won’t Save You
The myth of infinite serverless scale — why adding machines doesn’t fix overload, and what to do instead.