Eviction Policies

Deciding what to throw away

Caches have limited memory, so when full they must evict something. LRU (least recently used) evicts the entry unused for the longest time; it suits most workloads with recency patterns. LFU (least frequently used) evicts entries with the fewest accesses, protecting steady favourites from being pushed out by one-off scans. FIFO evicts the oldest inserted entry regardless of use. TTL-based policies evict entries closest to expiry. Modern in-process libraries use smarter hybrids: Caffeine in Java uses W-TinyLFU, which tracks frequency in a compact sketch and resists scans. Redis implements approximated LRU and LFU by sampling a few keys rather than tracking exact order, and its maxmemory-policy choices include allkeys-lru, allkeys-lfu, volatile-lru (only keys with a TTL), volatile-ttl and noeviction (reject writes when full). For a pure cache, allkeys-lru or allkeys-lfu is the usual choice.

Evicting the least valuable entry

When the cache is full, the policy picks the entry least likely to be needed again.

Redis memory and eviction settings

A dedicated cache instance with a hard memory cap and LFU eviction.

# redis.conf (cache-only instance)
maxmemory 6gb
maxmemory-policy allkeys-lfu     # evict least frequently used keys across all keys
maxmemory-samples 10             # more samples = closer to exact LFU/LRU, more CPU

# do not use noeviction for a cache: writes fail with OOM errors when memory is full
# monitor: INFO stats -> evicted_keys, keyspace_hits, keyspace_misses

Separate cache and data stores

If the same Redis instance stores both cache entries and important data such as queues or sessions, an eviction policy may delete the important data. Use separate instances, or volatile-* policies with TTLs only on cache keys.

Quick check: A cache sees regular full-table scans that pollute it with rarely used entries. Which policy family resists this best?

• LFU or TinyLFU-style frequency-based eviction
• FIFO
• LRU
• noeviction