Why Eviction Exists
Redis is an in-memory store, so when it approaches the configured maxmemory limit, it needs a strategy for what happens next. Without eviction enabled, Redis simply rejects new write commands with an OOM error once the limit is hit, which is safe for data integrity but breaks write-heavy applications outright. Eviction policies let Redis instead remove existing keys to make room for new writes, trading some data for continued availability — appropriate for cache-like workloads where losing an old entry is acceptable, but dangerous for workloads where every key represents data you can't regenerate.
Cricket analogy: It's like a stadium that's sold out simply turning away new fans at the gate (no eviction, OOM) versus one that lets in more fans by asking those who've been there longest near the exits to make room (eviction).
The Eviction Policies
Redis offers eight maxmemory-policy options. noeviction rejects writes on OOM. allkeys-lru and volatile-lru evict the least-recently-used key, across all keys or only among keys with a TTL set, respectively. allkeys-lfu and volatile-lfu evict based on access frequency rather than recency, which better suits workloads with a stable set of hot keys accessed often over a long period. allkeys-random and volatile-random evict a random key, cheap to compute but with no intelligence. volatile-ttl evicts the key with the nearest expiration time first, useful when you want to respect TTL-implied priority directly.
Cricket analogy: It's like a squad selector dropping the player who hasn't played a match in the longest time (LRU) versus dropping the player with the worst overall strike rate across the season regardless of recency (LFU).
Configuring Eviction
# redis.conf
maxmemory 2gb
maxmemory-policy allkeys-lfu
# Or dynamically:
redis-cli CONFIG SET maxmemory 2gb
redis-cli CONFIG SET maxmemory-policy allkeys-lfu
# Inspect current memory usage and eviction stats
redis-cli INFO memory | grep used_memory_human
redis-cli INFO stats | grep evicted_keysChoosing volatile-* vs allkeys-* Policies
The volatile-* policies only consider keys that have an explicit TTL set (via EXPIRE, SETEX, etc.); keys without a TTL are never evicted under these policies, which protects permanent data while still reclaiming space from expiring cache-like entries. If every key in your dataset is TTL-tagged and the rest is genuinely permanent, volatile-lru or volatile-lfu is safer than allkeys-* because it guarantees non-expiring keys survive memory pressure. If your instance is a pure cache where everything is disposable, allkeys-lru or allkeys-lfu is simpler and avoids the failure mode where all TTL'd keys get evicted first while permanent keys silently accumulate and eventually cause OOM anyway.
Cricket analogy: It's like a groundskeeper only allowed to clear temporary promotional banners around the ground (volatile) versus one allowed to take down any signage including permanent sponsor boards if space runs out (allkeys).
If you set a volatile-* policy but never assign TTLs to any keys, Redis has nothing eligible to evict and will fall back to rejecting writes with an OOM error once maxmemory is reached, behaving like noeviction. Make sure your key design actually matches the policy you choose.
Redis's LRU implementation is approximate, not exact: it samples a small number of keys (configurable via maxmemory-samples) and evicts the least-recently-used among that sample, trading a little eviction precision for much lower CPU overhead than maintaining a fully ordered structure.
- Eviction only matters once maxmemory is set; without it, Redis can grow unbounded until the OS runs out of memory.
- noeviction rejects writes with OOM once the limit is reached, preserving existing data but breaking availability.
- LRU policies evict least-recently-used keys; LFU policies evict least-frequently-used keys, better for stable hot-key workloads.
- volatile-* policies only evict keys with a TTL set, protecting permanent keys from eviction.
- allkeys-* policies can evict any key, appropriate for pure-cache deployments.
- A volatile-* policy with no TTL'd keys behaves like noeviction once memory fills up.
- Redis's LRU/LFU are approximate, sampling a configurable number of keys via maxmemory-samples rather than tracking exact global order.
Practice what you learned
1. What happens under the noeviction policy once maxmemory is reached?
2. What is the key difference between LRU and LFU eviction?
3. What distinguishes volatile-lru from allkeys-lru?
4. What happens if a volatile-* eviction policy is set but no keys have a TTL assigned?
5. How does Redis implement its LRU/LFU eviction in practice?
Was this page helpful?
You May Also Like
Redis Persistence Tradeoffs
A practical comparison of RDB snapshots and AOF logging in Redis, and how to choose or combine them based on your durability and performance needs.
Redis Cluster Explained
How Redis Cluster shards data across multiple nodes using hash slots, and how it handles failover and multi-key operations.
Redis Replication
How Redis copies data from a primary to one or more replicas for read scaling and failover readiness, and the consistency tradeoffs that come with it.