Why Eviction Matters
A cache has finite memory. When it fills up, Redis must decide what to remove to make room for new data. The wrong eviction policy causes either cache thrashing (constantly evicting data that's immediately needed again) or memory errors that crash your application.
TTL (Time To Live)
Every key in Redis can have an expiration time set in seconds or milliseconds. When the TTL expires, Redis marks the key as expired and removes it lazily (on next access) or actively (background sweep). Setting appropriate TTLs is the primary mechanism for keeping cached data fresh.
TTL Strategy Guidelines:
- Frequently changing data (stock prices, live scores): Short TTL — 5–30 seconds.
- Moderately changing data (user profiles, product listings): Medium TTL — 5–60 minutes.
- Rarely changing data (configuration, reference data): Long TTL — hours to days.
- Session data: TTL equal to session timeout (e.g., 30 minutes, sliding window).
Avoid TTL = 0 (no expiration) for data that can become stale. This leads to serving outdated data indefinitely and cache memory growing unbounded.
Redis Eviction Policies
When Redis reaches its maxmemory limit, it applies the configured eviction policy:
| Policy | Behavior | Best For |
|---|---|---|
noeviction |
Returns error on write when full | When you cannot afford data loss (use with caution) |
allkeys-lru |
Evicts least recently used keys across all keys | General-purpose caching |
volatile-lru |
Evicts LRU keys that have a TTL set | Mixed cache + persistent data in same instance |
allkeys-lfu |
Evicts least frequently used keys | Workloads with hot/cold key patterns |
volatile-lfu |
Evicts LFU keys with TTL set | Mixed workloads with frequency skew |
allkeys-random |
Evicts random keys | Uniform access patterns (rare) |
volatile-ttl |
Evicts keys with shortest remaining TTL | When you want soonest-to-expire data removed first |
LRU (Least Recently Used): Removes the key that hasn't been accessed for the longest time. Good default for most caches.
LFU (Least Frequently Used): Removes the key accessed least often over time. Better than LRU when your workload has a small set of "hot" keys accessed constantly and a large set of "cold" keys accessed rarely.
Production Recommendation: Use allkeys-lru for pure caching workloads. Use volatile-lru if you store both cached data (with TTL) and persistent data (without TTL) in the same Redis instance — though mixing these is an antipattern worth avoiding.
A common interview question: "Your ElastiCache cluster is returning OOM command not allowed errors. What's happening and how do you fix it?" The answer: Redis has hit its maxmemory limit and the eviction policy is set to noeviction. Immediate fix: switch to allkeys-lru eviction policy. Medium-term fix: increase node size or add shards (Cluster Mode Enabled). Root cause investigation: check if TTLs are set appropriately and whether the working set has grown beyond initial capacity planning.