Redis Caching Strategies: Cache-Aside, TTLs, Invalidation, Negative Caching, and Stampede Protection
Redis is most effective as a cache when the strategy defines who owns the truth, how entries expire, and what happens during misses or concurrent refreshes.
Cache-Aside: Strong Default
For read-heavy application data:
read Redis
→ on miss read database
→ populate Redis with TTL
On write, update the authoritative database first and then delete/invalidate the cache key. Redis's current guidance recommends this rather than trying to keep two authoritative copies synchronized manually.
TTLs Bound Staleness
Every cache entry should normally have a deliberate lifetime. Shorter TTLs improve freshness but increase misses; longer TTLs improve hit rate but allow older data to survive longer.
Use explicit invalidation for changes that should become visible quickly and TTL as a recovery/safety bound.
Negative Caching
Repeated requests for missing IDs can still overload the database. Cache a short-lived “not found” sentinel when safe.
Use a shorter TTL than normal positive entries so newly created records do not remain hidden for long.
Protect Hot Expirations
When one popular key expires, many requests can miss at the same moment and stampede the database.
Use one of:
- single-flight/request coalescing
- short lock around the refresh
- TTL jitter
- proactive/early refresh
Only one request should perform the expensive reload when practical.
Local + Redis Layering
For extremely hot small data, a local in-process cache can sit in front of Redis:
local cache → Redis → database
This removes a network hop but introduces another freshness layer. Use it only where short per-instance staleness is acceptable or invalidation is reliable.
What About Write-Through / Write-Behind?
Write-through or write-behind designs can be useful when the cache/data platform intentionally owns that write path, but they are more complex than ordinary cache-aside and change durability/failure semantics.
Do not adopt them merely to avoid one database read.
Final Takeaway
For most application caching, start with cache-aside + TTL + delete-on-write. Add negative caching and stampede protection where traffic justifies them, and introduce extra cache layers only when measured latency or source load proves the value.
References
Discussion (0)