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
Drop‑in rate limiting that prevents timeouts, lowers infra cost, and scales with your business.
Reliable at peak
Handle launch spikes and promos without timeouts or slowdowns.
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.
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.
Three pillars: rate limiting and load shedding
We use all three together—rate limits, latency‑based shedding, and memory‑based shedding—to keep critical flows fast while gracefully degrading non‑essentials.
Rate limiting
Fairness and abuse prevention. Predictable caps per customer/route keep traffic stable—even during spikes.
Latency‑based shedding
Protects shared resources (DB, caches, queues). When p95/p99 crosses thresholds, configurable shedding tiers drop non‑essential classes first while preserving core user flows.
Memory‑based shedding
Keeps compute from overflowing. Under memory pressure or deep queues, we back off expensive work first so hot paths stay responsive.
Fewer incidents
Shed non‑essentials so core experiences stay online.
Better UX under stress
Prioritize what users feel; degrade gracefully elsewhere.
Lower spend
Avoid emergency scaling and over‑provisioning for rare spikes.
Protected vs unprotected traffic
Protect critical flows before overload spreads
See how RateLimitly blocks abusive traffic early, sheds stressed work before it reaches expensive tiers, and keeps the load balancer, app servers, and database responsive.
Keep your API fast while latency-based shedding and local memory shedding protect shared infrastructure.
Choose a pressure event to compare what breaks without protection and what RateLimitly blocks or sheds before the app and database degrade.
Without protection
Every expensive tier absorbs the burst
Up
No immediate bottleneck, but no guardrails
No decision step ahead of the app
Normal traffic still works, but nothing stands between a spike and your expensive tiers.
Edge
Load balancer
Compute
App servers
CPU burns on abusive traffic
Threads pile up waiting on the DB
App memory climbs toward OOM
Storage
Database
Queries queue and time out
DB buffers swell under backlog
Live request path
No guardrails
Healthy baseline
Normal requests still work, but there is no decision point keeping future spikes away from the expensive path.
With RateLimitly
Block, shed, and stabilize before overload spreads
Up
Healthy requests continue with low friction
Healthy requests keep moving
Each application server talks to local RateLimitly, which makes fast decisions and keeps healthy traffic moving with low friction.
Abuse limiter
Latency tracker
Local memory shedding
Critical requests continue
Optional work dropped first
Reduced work protects the system
Edge
Load balancer
Compute
App servers
Healthy requests continue while the node protects its own memory.
Local shedding caps memory growth
Local guard
RateLimitly
Abuse limits + latency-aware decisions
Blocking abusive spike
Storage
Database
Latency tracker
Shed before overload
Spillover contained
Protected request path
Healthy requests allowed
Healthy baseline
Each app server uses local RateLimitly for fast decisions, so healthy traffic keeps moving with low friction.
Allowed
Healthy traffic continues
Blocked
Denied before expensive work
Shed
Trimmed under pressure
Current teaching point
Healthy traffic keeps moving while RateLimitly stays ready to block abuse, trim stressed DB work, and cap local memory before overload spreads.