Redis Eviction Policies & Memory Management

Overview

TTL (previous lessons) is proactive: you decided the key should die. Eviction is reactive: the process is at the ceiling and something has to give. Mixing those up is how sessions disappear while a million cold product cards remain — or how writes start failing at peak.

By the end of this lesson you should be able to:

• Set maxmemory on purpose and name the policy
• Contrast allkeys-* vs volatile-* vs noeviction
• Explain that Redis LRU is sampled, not a perfect linked list
• Say when LFU beats LRU
• Map blob / fields / queue / unique / ranked / log to Redis types
• Contrast RDB snapshots vs AOF everysec vs persistence off for a disposable cache
• List the metrics that show an eviction storm (and why hit rate drops)

maxmemory is a ceiling, not a plan

maxmemory is the hard cap on the dataset (with overheads — see used_memory vs used_memory_rss). When a command would pass the cap, Redis runs maxmemory-policy.

If you do not set it, Redis grows until the host is unhappy. The Linux OOM killer is an eviction policy with worse telemetry. Always set maxmemory on a cache, leaving headroom for the OS, replication buffers, and fragmentation.

Eviction is not capacity planning:

• If the working set does not fit, you will evict hot keys, miss, reload, evict, miss — a eviction storm
• TTL hygiene still matters; eviction does not fix unbounded key growth from a bug
• Hot-key CPU is not a memory problem; split keys or add L1
• Sizing still starts from "what must stay resident" plus overhead, then you pick a policy for the overflow

flowchart TB
  W["Step 1 Write arrives Ready"]
  M["Step 2 used_memory over maxmemory? Ready"]
  OK["Step 3 Store the value Ready"]
  P["Step 4 maxmemory-policy Ready"]
  E["Step 5a Reject the write with OOM reads still work Ready"]
  L["Step 5b Sample keys, evict the coldest Ready"]
  V["Step 5c Any keys with a TTL? Ready"]
  X["Step 6 Evict only among keys that have a TTL Ready"]
  W -->|continues| M
  M -->|no| OK
  M -->|yes| P
  P -->|noeviction - the default| E
  P -->|allkeys-lru or allkeys-lfu| L
  P -->|volatile-lru, volatile-lfu, volatile-ttl| V
  V -->|yes| X
  V -->|no| E
  L -->|continues| OK
  X -->|continues| OK

The policies

Redis ships several. You will be asked to pick, not to recite the man page.

allkeys vs volatile is the interview distinction. The Redis default is noeviction. volatile-* ignores keys with no TTL. volatile only considers keys with an expire set; if no key has a TTL, volatile-* behaves like noeviction and writes fail. That protects a session or a lock you stored without EX — and it means a cache that forgot to set TTL will not evict those keys. You can fill the instance with immortal junk and then fail writes. If every cache key has a TTL, volatile-lru and allkeys-lru behave similarly until someone SETs without EX.

Sampled LRU and LFU

Redis does not keep a perfect LRU list of every key (that costs memory you wanted for data). It samples a few keys (maxmemory-samples, default 5) and evicts the best victim in the sample. Higher samples → closer to true LRU, more CPU per eviction.

That approximation is why a "I just used that key" story can still lose it under pressure — unlikely if it is truly hot (it keeps getting resampled as young), possible if it is warm and unlucky. The playground uses the same idea with an item-count ceiling.

LRU (recency): a weekly report that was scanned an hour ago looks as hot as a session hit every second, until time passes. A one-off bulk read can protect a huge blob and evict a user key.

LFU (frequency): better when some keys are hit steadily and others are scanned once. Counter saturates and decays; you are not expected to derive the decay in an interview, only to say "recurring hot keys beat a recent scan."

volatile-ttl: among keys that will expire, drop the one closest to death. Good when TTLs are honest; bad when a 24h key is cold and a 30s key is hot — you might evict the hot one because it is "about to die," then immediately miss-reload it.

Operations

CONFIG SET maxmemory 2gb
CONFIG SET maxmemory-policy allkeys-lru
INFO memory
INFO stats

What you actually page on:

CONFIG SET is the live lever; persist it in redis.conf / the operator's CRD or you will lose the policy on restart.

Fragmentation: Redis uses jemalloc. After a huge delete wave, used_memory falls and RSS may not. That is not "eviction failed." Restart or a compacting story is an ops choice; do not "fix" it by switching to noeviction.

Replication and persistence eat memory too (client-output-buffer, AOF rewrite). maxmemory does not mean "the rest of the box is free."

Tie-back to the cluster

• Cache-aside assumes a miss can rebuild. Evicting a hot key is just a miss — unless you stampede. Keep single-flight.
• Write-behind that treated Redis as the only copy of an unflushed write: eviction is a lost write. Do not do that.
• TTL jitter still applies. Eviction is not a substitute for expiry cliffs.
• Locks (SET NX PX) have a TTL; they are volatile. A volatile-* policy may evict a lock under pressure — which looks like a released mutex. Keep lock keys small and lock TTL short; do not store 2 MB values next to them on a tiny maxmemory.

Data structures — pick from the access pattern

Redis is an in-memory data structure server, not only a string blob store. Wrong type is a hot-key tax.

• String — blobs, counters (INCR), bitmaps / HyperLogLog overlays.
• Hash — object fields (HSET user:1 name Ajay); partial reads.
• List — queues / stacks (LPUSH / BRPOP).
• Set — unique membership, intersections.
• Sorted set — leaderboards, time indexes (ZADD score).
• Stream — durable-ish log for consumers / CDC-like patterns.

Hash vs JSON string: hash allows partial field updates/reads; JSON string is simpler but rewrite-whole — races with invalidation. Streams vs lists for jobs: streams give consumer groups / ACK; lists are simpler blind queues.

Do not cache huge blobs or unbounded lists. Paginate, or cache IDs and hydrate. Hot keys: local near-cache, hashing/splitting, read replicas carefully (lag).

Persistence: RDB vs AOF vs none

RDB: fork + point-in-time snapshot. Compact; faster restores; can lose minutes of data since last save.

AOF: append every write (or batched). appendfsync everysec is the usual compromise — caps loss at about 1s without syncing every write. Rewrite compacts AOF over time.

Both: common production — AOF for durability, RDB for backups.

None: pure disposable cache with a known cold-start plan and stampede defenses. RDB/AOF would only slow failover for data you can rebuild.

Treat Redis as a durable DB with no AOF/replicas → node death loses "acknowledged" writes (especially write-behind buffers). Write-behind on RDB-only Redis can lose the recent buffer — prefer AOF or an external WAL.

Async replicas for read scaling / HA (Sentinel or managed ElastiCache). Replication lag ⇒ stale reads from replicas — same class of problem as near-cache staleness. Do not read replicas for a compare-and-set that assumed the primary.

Working sketches

# Sketch against a real client — not runnable here.
def memory_report(r) -> dict:
    info = r.info("memory")
    stats = r.info("stats")
    conf = r.config_get("maxmemory*")
    return {
        "used_memory_human": info.get("used_memory_human"),
        "maxmemory_policy": conf.get("maxmemory-policy"),
        "evicted_keys": stats.get("evicted_keys"),
    }

// INFO memory + INFO stats + CONFIG GET maxmemory-policy
// Alert on evicted_keys rate, not on the counter's lifetime total

Tiny sampled-LRU (run this)

Item count stands in for maxmemory. Contrast noeviction (write error), allkeys-lru (cold keys leave, even durable ones), volatile-lru (no-TTL session survives).

Press Run. Snippets must be self-contained — no network, files, or native modules.

noeviction keeps a,b,c and errors on d. volatile-lru keeps session:1 because it has no TTL. allkeys-lru may keep the session because we touched it — recency — but it could have evicted it; that is the mixed-workload argument.

Mini structures (run this)

Strings with a tiny LRU ceiling, plus hash and zset. Educational only — not Redis protocol.

Press Run. Snippets must be self-contained — no network, files, or native modules.

Interview Q&A

Pitfalls

Go Deeper

Official docs

• Redis eviction policies
• Redis memory optimization
• Redis CONFIG SET
• Redis data types
• Redis persistence

In this cluster

• Negative caching
• Next: Cache invalidation
• Hub: Redis cache-aside, invalidation, stampede