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 24 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.
Little’s law worked example
-
Throughput
100 operations / s
Same measurement boundary
-
Average time
0.1 s
Not a minimum
-
Average in flight
10 operations
100 × 0.1
Illustrative mechanism. Highlight follows the explanation; not a benchmark.
Read the numbered steps in order. The explanation below follows the narration.
Stable example: throughput × average time = average in flight.
Latency is useful feedback, not an exact queue or spare-capacity measurement.
0:00
Read transcript & diagram walkthrough
What you will learn
Latency is useful feedback, not an exact queue or spare-capacity measurement.
The latency signal is useful because longer operations can keep more work unfinished. Consider a system completing one hundred operations per second. In a stable period, if each operation spends one tenth of a second inside the chosen boundary on average, there are ten operations inside it on average.
In a different stable period, the same completion rate and half a second of average time correspond to fifty operations inside. Average time means the total time divided by the number of operations. Little's law is the relationship between these averages: work in flight equals throughput multiplied by time.
RateLimitly does not insert its minimum into that formula. A minimum and an average are different numbers. The tracker therefore does not calculate an exact queue size or read the database's remaining memory. Communication delays, slow computation, and connection waiting can all affect the chosen measurement.
Use latency feedback to decide when adding work looks unwise, not to claim perfect knowledge of spare capacity. A sudden failure can happen before enough new reports arrive. Independent resource bounds and operational monitoring still have jobs to do.
Diagram walkthrough
-
Stable example: throughput × average time = average in flight.
For a stable period and a consistent boundary, average work in flight equals throughput multiplied by average time.
-
A longer average time retains more work at the same throughput.
Derived examples: 100 × 0.1 = 10; 100 × 0.5 = 50. Longer time can retain more simultaneous work even with the same completion rate.
-
The tracker minimum is not the average in this equation.
RateLimitly does not substitute its minimum sample into Little’s law. Minimum and average are different statistics.
-
Combine feedback with independent safeguards.
The signal is evidence for admission, not an exact measurement of queue length, spare memory, utilization, or stability.
Content revision: 07c7dd00db17
Download review copy (27 lessons)Check your understanding & apply it
Can you substitute the tracker’s recent minimum for the average time in Little’s law?
Show the explained answer
No. Little’s law relates compatible averages under appropriate conditions. The tracker’s minimum is a different signal.
Integration guidance
Calibrate and test thresholds against real workload behavior while keeping independent resource limits and monitoring.
Where the promise stops
The 10- and 50-operation examples describe separate stable periods, not an exact estimate during a growing transient queue.
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.
-
Measure the operation whose pressure you want to observe
Define one meaningful stopwatch boundary before interpreting its measurements.
-
Even the fastest recent observations can become slow
The eligible recent minimum is a pressure signal with freshness and missing-data limits.
Implementation detail
Use consistent measurement boundaries and compatible averaging intervals. Neither latency alone nor a minimum establishes cause, utilization, memory, or stability.
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.