A Redis Eviction Policy Decides Which Writes Can Fail

A voice assistant might keep replayable audio snippets beside the cursor that records where a conversation will resume. Both are Redis keys, but losing them has different consequences. Once the instance reaches its configured maxmemory, the eviction policy decides whether Redis removes a key or refuses a memory-growing command. That policy is part of the application’s failure behavior.

Draw the eviction boundary

With noeviction, Redis retains keys and returns an error for commands that need to add data after the limit is reached. Reads of existing data continue. This protects the conversation cursor from eviction, but a new cursor or cache write can fail. The application must check the write reply and have a recovery path; merely choosing noeviction cannot create capacity.

allkeys-lru and allkeys-lfu let Redis reclaim space from any key. LRU favors recently accessed keys; LFU favors frequently accessed keys, with older frequency decaying over time. Both are approximations. They fit a cache whose entries can be rebuilt, such as generated snippet previews. On a shared instance, a cursor without an expiry is still eligible for eviction under an all-keys policy. Persistence settings do not change that selection rule. Redis’s eviction guide describes the policy families and their eligibility rules.

The volatile-lru and volatile-lfu variants consider only keys with an expiry. If snippets have a time to live and cursors do not, those policies keep cursors outside the eviction pool. That boundary depends on correct TTL assignment: an accidental expiry makes a cursor eligible, while cache entries without expiry cannot be reclaimed by the policy. When no expiring keys are available, volatile policies behave like noeviction and growth writes can fail. volatile-ttl instead chooses eligible keys with the shortest remaining life.

Check the pressure you actually have

Redis reports evicted_keys, expired_keys, cache hits and misses, and rejected commands through INFO. Look at those alongside application write errors. For policies that evict keys, replication and append-only-file update buffers are excluded from the memory compared with maxmemory. Redis recommends leaving RAM headroom for those buffers on replicated or persisted instances; the guide exempts noeviction from this recommendation.

For a new design, put rebuildable AI cache entries and recovery-critical conversation state on separate instances when practical. If they must share one, give every disposable entry a TTL, choose a volatile policy deliberately, and test both key survival and write-error handling at the memory limit.