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 15 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.
Fairness versus resource isolation
-
Tenant · N
Its useful work
Should not lose every resource
-
Containment boundary
Limit spread
Strength depends on mechanism
-
Tenant · O
Excessive work
Contains the noisy neighbor
Illustrative mechanism. Highlight follows the explanation; not a benchmark.
Read the numbered steps in order. The explanation below follows the narration.
A bulkhead contains the spread of trouble.
Tenant fairness is bulkhead-like containment, not a guarantee of reserved resources.
0:00
Read transcript & diagram walkthrough
What you will learn
Tenant fairness is bulkhead-like containment, not a guarantee of reserved resources.
A ship's bulkhead separates compartments so trouble in one does not flood every other compartment. In software, a bulkhead separates resources or work so one part cannot consume everything. Resource isolation means setting aside or bounding resources for a particular part.
A tenant rate limit is bulkhead-like: it contains excessive arrivals from one customer and makes other customers less likely to suffer. That is a valuable fairness boundary. But it does not necessarily reserve a processor, memory, database connections, or active execution slots for Maya.
Imagine two tenants each start ten requests. One tenant's requests finish quickly. The other's requests remain active and retain much more memory. Equal request counts did not create equal resource use. Work weights can improve the allowance, but strict resource separation may require separate pools or additional concurrency bounds.
Choose the strength of the promise carefully. Say that the rate limit contains a tenant's excessive use. Do not say that rate limiting alone makes every tenant fully isolated from every other tenant.
Diagram walkthrough
-
A bulkhead contains the spread of trouble.
A software bulkhead separates or bounds resources so trouble in one part does not consume everything in another part.
-
A rate limit contains arrivals, not every resource.
A tenant rate limit is bulkhead-like: it contains excessive arrivals. It does not necessarily reserve memory, connections, or execution slots.
-
Ten quick requests and ten long requests are different.
Ten short operations and ten long operations have equal counts but different retained-work costs. Weights improve accounting; they do not create strict isolation.
-
Match the promise to the protection.
Name the actual guarantee: recent-use fairness, concurrency separation, or a dedicated resource budget. They are different protections.
Content revision: 07c7dd00db17
Download review copy (27 lessons)Check your understanding & apply it
Does an equal request allowance reserve equal memory for each tenant?
Show the explained answer
No. Duration and per-request cost differ. Strict resource isolation needs additional resource controls.
Integration guidance
Use tenant rate limits for excessive arrivals; add separate bounded pools or concurrency controls when you need stronger isolation.
Where the promise stops
A rate limit alone does not reserve CPU, memory, active slots, or database connections.
Technical depth & sources
Concepts used here
Start here. No earlier lesson is required.
-
Retained work can exhaust a process’s memory
Waiting work can retain memory. A failed allocation or terminated process can stop service.
-
Different compute platforms still have finite resources
Serverless and autoscaling change how compute is supplied, not whether resources are finite.
-
A rate limit checks one customer’s recent allowance
A rate limit enforces an allowance, not a measurement of current resource health.
Implementation detail
Distinguish admission accounting from resource scheduling. State which resources are actually bounded or separated.
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.