# Eviction Policies — Caching Strategies & CDN Design

Source: https://www.skillbyai.com/en/caching-strategies/d-eviction

> Choose an eviction policy and configure memory limits sensibly.

## 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.

![A full row of boxes with one faded box at the end being pushed out as a new box enters from the other side.](assets/figures/caching-strategies/section-5-map.svg) — Figure 5.1 — An eviction policy making room for a new entry.

## Redis memory and eviction settings

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

```text
# 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.

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

- [x] LFU or TinyLFU-style frequency-based eviction
- [ ] FIFO
- [ ] LRU
- [ ] noeviction

*Answer:* LFU or TinyLFU-style frequency-based eviction. Frequency-based policies keep popular entries even when a scan touches many one-off keys.