Skip to content

Redis Eviction Policies

When Redis reaches its configured memory limit (maxmemory), it must evict (delete) some keys to make room for new writes. The eviction policy decides which keys to remove.

Analogy: Eviction is like your refrigerator being full — when you need to add something new, you must throw away old items. The policy decides whether to throw away the oldest, the least used, or whatever is expiring soon.

flowchart TB
App[App writes new data<br/>SET / LPUSH / SADD etc.] --> Check{Is Redis<br/>over maxmemory?}
Check -->|No ✅| Accept[Store the data normally]
Check -->|Yes ❌| Policy{Which eviction<br/>policy is set?}
Policy -->|noeviction| Reject[Return error<br/>Writes rejected]
subgraph Lru[LRU — Least Recently Used]
LRU1[Remove keys that<br/>haven't been accessed<br/>the longest]
end
Policy -->|allkeys-lru| Lru
subgraph Lfu[LFU — Least Frequently Used]
LFU1[Remove keys that<br/>are accessed the<br/>least often]
end
Policy -->|allkeys-lfu| Lfu
subgraph Ttl[TTL — Expiring Soonest]
TTL1[Remove keys with<br/>the shortest TTL /<br/>nearest expiration]
end
Policy -->|volatile-ttl| Ttl
subgraph Random[Random]
RAND1[Remove a<br/>random key]
end
Policy -->|allkeys-random| Random
Lru --> Evict[Evict selected key(s)]
Lfu --> Evict
Ttl --> Evict
RAND1 --> Evict
Evict --> Check
style App fill:#3b82f6,color:#fff
style Check fill:#f59e0b,color:#fff
style Accept fill:#059669,color:#fff
style Reject fill:#ef4444,color:#fff
style Policy fill:#7c3aed,color:#fff
style Lru fill:#7c3aed,color:#fff
style Lfu fill:#3b82f6,color:#fff
style Ttl fill:#f59e0b,color:#fff
style Evict fill:#ec4899,color:#fff

PolicyDescriptionBest For
noevictionReturn error on writes when full (default)When every key matters
allkeys-lruEvict least recently used keys from all keysGeneral-purpose caching ✅
allkeys-lfuEvict least frequently used keys from all keysWhen access frequency matters
allkeys-randomEvict a random keySimple, predictable eviction
volatile-lruEvict LRU from keys with TTL set onlyMixed caching + persistent data
volatile-lfuEvict LFU from keys with TTL onlyWhen TTL keys have varying frequency
volatile-ttlEvict keys with the shortest remaining TTLWhen expiry is the priority
volatile-randomEvict random key from TTL keys onlySimple eviction for TTL keys

Terminal window
# Set maximum memory (e.g., 256 MB)
maxmemory 256mb
# Set eviction policy
maxmemory-policy allkeys-lru
# For LRU/LFU: sample size for approximation (default 5)
maxmemory-samples 10 # Higher = more accurate, slower

Terminal window
# allkeys-lru — removes keys you haven't touched recently
# Good for: Most caching use cases
# Example: User session data — old sessions get evicted first
# allkeys-lfu — removes keys you rarely access
# Good for: Content caching where some items are "evergreen"
# Example: Product catalog — popular products stay cached
# volatile-ttl — removes keys about to expire
# Good for: When you only want to evict TTL keys
# Example: OTP codes — ones about to expire are removed first

Example 1: General Cache (Recommended)

Terminal window
maxmemory 512mb
maxmemory-policy allkeys-lru

Example 2: Session Store Only

Terminal window
maxmemory 1gb
maxmemory-policy volatile-ttl
# Only keys with TTL get evicted — persistent keys stay safe

Example 3: Mixed Data (Cache + Persistent)

Terminal window
maxmemory 2gb
maxmemory-policy volatile-lru
# Cached data (with TTL) gets evicted before persistent data

MistakeWhyFix
No maxmemory setRedis uses all available RAMAlways set maxmemory
Using noeviction for cachingWrites fail when fullUse allkeys-lru instead
Setting maxmemory-policy without maxmemoryPolicy has no effect without a limitAlways set both

  • Eviction is Redis’s way of freeing memory when it’s full
  • allkeys-lru is the best default for most caching use cases
  • noeviction (default) just returns errors — only use if data loss is unacceptable
  • LFU tracks access frequency; LRU tracks access recency
  • Always set maxmemory and maxmemory-policy together in production