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 5 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.
Working-memory budget
-
Memory
Working space
Temporary state used while the program runs.
-
Storage
Different purpose
Stored records are not these tiles.
Illustrative space, not measured bytes. B is the running program; R is retained request state; dashed empty tiles are free space.
Read the numbered steps in order. The explanation below follows the narration.
Memory is working space; a process is a running program.
Waiting work can retain memory. A failed allocation or terminated process can stop service.
0:00
Read transcript & diagram walkthrough
What you will learn
Waiting work can retain memory. A failed allocation or terminated process can stop service.
Memory is an application's working space, not permanent storage. A process is a running program. It uses memory even before customers arrive. While Maya waits for her report, the application can hold her request details, temporary data, and connection information. Waiting is not free.
After the work finishes and cleanup releases those resources, space can become available again. But if more requests remain unfinished, more state stays in memory. Our tiles illustrate that accumulation; they are not measured bytes per request. Maya closing her browser does not itself release this state. The application must finish or cancel the work and clean up.
A container is an environment for running a program. It can have an enforced memory limit. The host machine can still have free memory while this container reaches its limit. Asking for additional memory is an allocation. If the required memory cannot be provided, we have an out-of-memory condition, or OOM. An allocation can fail, or a process can be killed; the outcome depends on the runtime and system policy.
If the serving process is killed, this copy stops serving requests. Maya gets no report from it. The whole machine has not necessarily failed, and stored data has not necessarily been lost. The lesson is to protect room for finishing work, cleanup, and responses before reaching a hard limit. Refusing more work also costs resources. Waiting until memory is completely exhausted is too late to rely on an orderly refusal.
Diagram walkthrough
-
Working space is different from permanent storage.
The application needs working space to run. This picture represents one application’s memory budget, not its database records or the size of the entire host computer.
-
The running program already uses some memory.
The tiles marked B represent the program’s existing memory use. This is a qualitative illustration: we are not assigning a fixed number of bytes to every request or runtime.
-
Her waiting request retains real resources.
The new R tile represents request details, temporary buffers, and connection state retained while Maya waits. The request can occupy memory without producing a useful result yet.
-
Finishing and cleanup can release working space.
In this successful alternative, the work finishes and cleanup releases the request’s resources. Actual memory reuse and return to the operating system depend on the runtime; completion alone is not proof of immediate reclamation.
-
Alternative: unfinished requests accumulate.
Return to the waiting case. More requests remain in flight and retain more state. The running program has not become larger in this simplified picture; the extra occupied space belongs to unfinished work.
-
The tiles explain the mechanism, not a benchmark.
Different requests can retain very different amounts of memory. These equal visual tiles help track occupied and free space; they are not a prediction of bytes, request capacity, or a safe production threshold.
-
The caller leaving does not clean up the server.
The R tiles remain: Maya’s browser giving up is not evidence that the application cancelled the underlying work. The application must finish or cancel it and release the resources it owns.
-
A program can have its own enforced boundary.
A container is an environment for running a program and may have an enforced memory limit. That limit is a ceiling on this environment’s use, not a claim that the host reserves these exact physical tiles.
-
Host-wide free RAM does not remove a container limit.
The illustrated container has reached its own boundary even though the host may still have free RAM. Looking only at machine-wide memory can miss the limit that actually stops this application.
-
An allocation is a request for more working space.
The application asks the runtime or operating system for additional memory. If the required memory cannot be provided after the applicable reclamation and enforcement behavior, that is an out-of-memory condition.
-
There is more than one possible failure mode.
An allocation may fail and be handled by the program, or system policy may terminate a process. These are alternative possibilities, not a guaranteed two-step chain or a rule that the largest process always dies.
-
This copy stops serving. Maya gets no report.
Follow the process-termination branch: the application copy serving Maya is stopped. That does not automatically mean the whole host failed, every replica stopped, or permanent records were lost.
-
Act before the hard limit leaves no room to respond.
Return to a running application with some free space. Keep enough room for accepted work, cleanup, and responses; even refusing a request consumes resources. A check made only after total exhaustion cannot guarantee an orderly refusal.
Content revision: 07c7dd00db17
Download review copy (27 lessons)Check your understanding & apply it
Maya closes her browser. Does the application automatically release everything her request holds?
Show the explained answer
No. The application must finish or cancel that work and release its resources; the browser giving up does not establish that cleanup happened.
Integration guidance
Track retained work and the enforced process/container budget. Check cancellation and cleanup, including requests whose callers have gone away.
Where the promise stops
The illustrated termination is one possible OOM outcome. Victim selection and failure scope vary.
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.
-
More waiting space does not make work finish faster
Bigger buffers buy time. Caching can remove work. Backpressure reduces incoming work.
Implementation detail
Include garbage collection, native allocations, connection buffers and enforcement scope when selecting headroom; a single ratio cannot cover every runtime.
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.