Concept · Caching
Eviction policies
LRU, LFU, FIFO and TTLs: deciding what to drop when the cache is full.
A cache has a fixed amount of memory. When it's full and a new entry arrives, an eviction policy decides what to remove. The goal is to keep the items most likely to be read again.
| Policy | Evicts | Good for | Weak spot |
|---|---|---|---|
| LRU (least recently used) | The item not read for the longest | Most workloads: recency predicts reuse | A one-off scan of many keys flushes out the hot set |
| LFU (least frequently used) | The item read least often (with decay over time) | A stable set of consistently popular items | Slow to adapt when popularity shifts, without decay |
| FIFO | The oldest inserted item | Simplicity | Evicts hot items just because they're old |
| Random | Any item | Very cheap; surprisingly decent | Unpredictable |
| TTL / expiry | Only expired items | Bounding staleness | Doesn't free memory if nothing has expired |
Real caches combine TTL expiry with a capacity policy. Redis implements approximate LRU and LFU by sampling keys, which is far cheaper than tracking exact order. Newer designs combine a frequency sketch with recency and resist scans well: W-TinyLFU in Java's Caffeine, and TinyLFU admission in Go's Ristretto.
Redis settings that matter
maxmemory 4gb
maxmemory-policy allkeys-lfu # or allkeys-lruallkeys-lru/allkeys-lfu: evict any key — right for a pure cache.volatile-lru/volatile-ttl: evict only keys that have a TTL — for instances that mix cache data with data that must stay.noeviction(the default): reject writes when memory is full — right for a database, wrong for a cache.
Watch
Track the hit rate and the eviction rate together. A high eviction rate with a falling hit rate means the cache is too small for the working set; more memory, or caching less per item, helps. See caching patterns.