Redis Eviction Policy Guide: Choosing maxmemory-policy

The exact query engineers type into a search bar at 2 a.m. is usually some version of "redis eviction policy production" or "why is redis dropping my keys." The short answer: Redis only evicts keys because you told it to, either explicitly through maxmemory-policy or implicitly by leaving the default noeviction in place until writes start failing. Which of the eight policies is right for your service depends on whether Redis is a pure cache, a session or queue store, or a mix of both — and that answer changes again once traffic is sustained rather than bursty. This guide walks through the mechanics, the trade-offs, and a rollout checklist you can apply to a production cluster this week.

What actually happens when Redis hits maxmemory

Redis ships with maxmemory-policy set to noeviction. That is not a safe default for most SaaS workloads — it means once used_memory reaches maxmemory, Redis rejects every write command that would consume more memory (SET, LPUSH, HSET, SADD, and friends) with an OOM error, while reads keep working. If your application does not catch that error explicitly, a checkout flow, a session write, or a queue enqueue silently fails at exactly the moment traffic is highest, because that is when memory pressure peaks. Teams who never touch maxmemory-policy usually discover this the same way: a spike in 500s that correlates with a memory graph flatlining at the ceiling, not with CPU or network.

Eviction policies exist to make that failure mode a deliberate choice instead of an accident. Instead of rejecting the write, Redis frees space by deleting existing keys according to the policy you configure, then completes the write. The trade-off is explicit: you are choosing to lose some data to keep the service available, and the policy determines which data you lose first.

The eight maxmemory-policy options, compared

In practice, production traffic settles on two policies almost every time. If the Redis instance is exclusively a cache — API responses, rendered fragments, computed aggregates — allkeys-lru is the pragmatic default: it needs no per-key TTL bookkeeping, it is memory-efficient because you do not pay the ~8 extra bytes per key for an expiry field on every entry, and it degrades gracefully under a typical Zipfian (power-law) access pattern where a small set of keys absorbs most of the traffic. If the same instance also holds session tokens, rate-limit counters, or queue metadata that must not be evicted, volatile-lru with TTLs set only on the cache keys keeps the durable keys off the eviction table entirely, because volatile- policies never touch keys without an expiry.

Match the policy to the workload, not the default

• Cache-only (API/query cache, fragment cache): allkeys-lru, or allkeys-lfu if your dashboards show a stable long-tail of rarely-reused keys that LRU keeps evicting too slowly.
• Session store: volatile-lru or volatile-ttl, with an explicit EXPIRE on every session key — never noeviction, since a full instance should degrade to shorter sessions, not failed logins.
• Job queue (BullMQ, Laravel Horizon, Sidekiq-style lists/streams): noeviction on a dedicated instance separate from the cache. Losing a queued job silently is worse than a write erroring loudly, so isolate queue data from cache data at the instance or cluster level rather than trusting a shared policy to protect it.
• Rate limiting / counters: volatile-lru with short TTLs; losing a counter early just resets a window slightly sooner, which is a safe failure mode.
• Mixed instance you cannot split yet: volatile-lru as a bridge, with a migration plan to separate cache and durable data into different logical databases or clusters.

Sustained load changes the calculus

Eviction policy choices that look fine in staging often break down under weeks of sustained production traffic for three reasons. First, LRU in Redis is approximated, not exact — by default Redis samples 5 keys (maxmemory-samples) and evicts the oldest of that sample, which is cheap but means true "least recently used" accuracy degrades as your keyspace grows into the tens of millions. Raising maxmemory-samples to 10 improves accuracy at a small CPU cost and is worth it once a single node holds more than a few million keys under real eviction pressure. Second, memory fragmentation compounds over time: Redis's allocator (jemalloc by default) can leave used_memory reporting well below what the OS actually has resident, so mem_fragmentation_ratio creeping toward 1.5 or higher under sustained load means eviction is being triggered later than it should, or not accurately reflecting real headroom — that is a signal to schedule a rolling restart or upgrade Redis, not to loosen the eviction policy further. Third, sustained load exposes hot keys: a policy tuned for an even distribution will thrash if 1% of keys take 90% of traffic, because LRU eviction and the active-expire cycle both compete for CPU with the read/write load on those same hot keys, adding latency spikes exactly when you can least afford them.

The practical fix for hot-key thrash under an eviction policy is usually smaller and shorter-lived cache entries with jittered TTLs (so keys do not all expire in the same millisecond and stampede the origin), not a different eviction algorithm. Combine that with client-side caching (RESP3 tracking) for the hottest handful of keys so Redis is not even asked for them on every request.

Monitoring: catch evictions before they become an outage

Every eviction policy other than noeviction is, by definition, deleting data your application did not ask to delete. The only way to know whether that is happening at an acceptable rate is to watch it directly rather than infer it from error rates.

1. Track evicted_keys from INFO memory (or Redis Exporter for Prometheus) as a rate, not a cumulative counter — a sudden slope change is the earliest signal of memory pressure, well before OOM errors appear.
2. Alert on used_memory approaching maxmemory (e.g. 85%) so you have time to scale before eviction rate spikes, not after.
3. Watch keyspace_misses alongside evicted_keys — rising misses with rising evictions means your working set no longer fits in memory and you need more capacity, not a smarter policy.
4. Track mem_fragmentation_ratio; sustained values above 1.5 mean real usable memory is lower than the raw metric suggests.
5. For volatile- policies, confirm with DBSIZE vs the count of keys with a TTL that your durable keys actually have no expiry set — a missing EXPIRE call on a key you meant to protect is the most common production incident tied to eviction policy.

Rollout checklist for changing maxmemory-policy in production

1. Audit which keys currently have a TTL vs none, and confirm that split matches your intended cache vs durable-data boundary.
2. Set maxmemory explicitly (never rely on the OS default) and leave 20-25% headroom below the container or instance memory limit for fragmentation and replication buffers.
3. Change the policy on a replica first if using replication, verify behavior under a synthetic load test, then promote.
4. Set maxmemory-samples to 10 if your keyspace exceeds a few million keys and CPU headroom allows it.
5. Add evicted_keys, used_memory percentage, and mem_fragmentation_ratio to your existing dashboards before the change ships, not after.
6. Re-test the change under your actual peak traffic pattern, not average load — eviction behavior is a sustained-load problem, and averages hide it.

None of this replaces the broader scaling work — sharding, replica topology, connection pooling — that keeps a Redis cluster healthy as traffic grows; eviction policy is one layer of that stack, and it's often the layer teams configure once during setup and never revisit as data volume and traffic pattern change underneath it.