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 14 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.
Shared policy across languages
-
Python app
One local allowance
Same tenant · O
-
JavaScript app
Another local allowance
Same tenant · O
-
Effective policy
Accidental multiplication
More copies, more allowance
Illustrative mechanism. Highlight follows the explanation; not a benchmark.
Read the numbered steps in order. The explanation below follows the narration.
Separate local allowances can multiply one customer’s share.
Use the same API key, tenant bucket name, window, and allowance across every client.
0:00
Read transcript & diagram walkthrough
What you will learn
Use the same API key, tenant bucket name, window, and allowance across every client.
One customer may reach several application copies, written in different programming languages. If each copy gives Orchid its own full allowance, adding copies also multiplies Orchid's effective allowance. The policy has changed without anyone intending it.
RateLimitly is a service that applications ask for rate and latency decisions. A client library is code that lets your program make those calls. The API key defines which RateLimitly servers those libraries use. Keep it on the trusted application side.
A bucket is the named usage record for a rate-limit policy. Use the same API key, the same tenant-derived bucket name, and the same time window and allowance across the client libraries. The libraries then apply the intended policy across your application copies instead of giving each copy its own allowance.
For example, Orchid's report requests should use the same bucket whether they come through Python or JavaScript. Adding an application copy or changing languages should not grant Orchid another share. Use distinct tenant-derived names for different customers so one customer's use is accounted for separately.
Diagram walkthrough
-
Separate local allowances can multiply one customer’s share.
Independent full allowances per application copy multiply a tenant’s effective budget when the fleet grows.
-
The API key defines which RateLimitly servers the libraries use.
The API key defines which RateLimitly servers the libraries use. Keep the key in trusted application code, not the public browser.
-
Use the same API key, tenant bucket name, window, and allowance.
Use the same API key, tenant-derived bucket name, time window, and allowance across the libraries. Each application copy applies the intended policy.
-
Changing languages does not give Orchid another share.
Orchid uses the same named policy through Python and JavaScript. Different customers use distinct tenant-derived bucket names, keeping their usage separate.
Content revision: 07c7dd00db17
Download review copy (27 lessons)Check your understanding & apply it
Orchid's report moves from Python to JavaScript. Should that give Orchid another allowance?
Show the explained answer
No. Use the same API key and the same tenant-derived bucket name, window, and allowance so both clients apply the same intended policy.
Integration guidance
Configure every client library with the same API key, tenant-derived bucket name, time window, and allowance. Keep the key on the trusted application side.
Where the promise stops
This example covers one tenant's named policy under the same API key. It does not reserve memory or execution slots.
Technical depth & sources
Concepts used here
Start here. No earlier lesson is required.
-
One failed copy can push its neighbors over capacity
240 requests/s ÷ 3 = 80 each; after one loss, 240 ÷ 2 = 120 each.
-
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
Bucket identity is derived from its logical name, time window, and rate limit. Changing those settings defines a different policy; each request's work weight does not change the bucket identity.
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.