Redis eviction policies determine how Redis handles keys when memory reaches the configured limit used for eviction decisions. They are operational choices with application consequences: removing a replaceable cache entry is different from losing a session, a queue item, or another piece of authoritative state.
The first question is therefore not which policy produces the best benchmark. It is what data may safely disappear and how the application responds when a write is rejected or a value is absent. This guide connects memory settings to those real behaviors.
Classify the data before choosing a policy
List key families, their purpose, their expected lifetime, and whether the value can be reconstructed. A derived cache entry may be rebuilt from a database. A rate-limit counter or session record can have different correctness and security requirements. Treating every key as disposable can create subtle failures.
Separate workloads when their loss semantics differ. Sharing one instance between a disposable cache and durable application state makes memory pressure difficult to handle safely. Logical key prefixes do not independently enforce different eviction policies for each family.
Record application ownership and expected miss behavior. The client should know whether a missing key means recompute, deny access, retry, or raise an operational error. An undocumented default can be more dangerous than the eviction choice itself.
Understand maxmemory and headroom
The maxmemory setting controls the limit used by Redis’s memory-management behavior. It is not a guarantee that the entire process will never consume more memory. Redis documents buffers and other memory considerations that must be accounted for when sizing a host or container.
Leave capacity for replication, persistence-related behavior, and the rest of the environment according to the deployed configuration. Review Redis’s memory information, including values relevant to memory excluded from eviction accounting. A limit equal to the container’s total memory budget can leave no room for required overhead.
Test large writes and representative data shapes. A small set of average-sized keys does not model a workload with occasional large values or bursts. Memory planning needs both normal usage and credible peaks, including the time it takes your application to react.
Match the policy to the loss model
Allkeys policies consider keys broadly, while volatile policies restrict candidates to keys with an expiration. Variants use different selection strategies, including approximations based on recent or frequent use. Read the exact supported policy descriptions rather than assuming a name describes an exact mathematical guarantee.
A volatile policy can behave unexpectedly when eligible keys are absent or insufficient. Adding a TTL to a few cache keys does not make every other key safely manageable under memory pressure. Inspect the proportion and purpose of expiring keys.
Noeviction avoids automatically evicting keys but can return errors for commands that require additional memory when the limit is reached. That is not the same as unlimited safe storage. The client must handle the rejection, and operations must address capacity or data lifecycle before the error becomes persistent.
Distinguish expiration from eviction
Expiration removes keys according to their TTL lifecycle. Eviction responds to memory pressure under the configured policy. Both can produce a missing key, but the reasons and timing are different. Application code should not assume a value remains available until its TTL simply because a TTL was set.
Choose TTLs from business and freshness requirements. A long TTL on every cache entry can increase memory pressure and retain obsolete information. A short TTL can create frequent misses and excessive dependency traffic. Neither is a universal substitute for appropriate memory sizing.
Review security-sensitive caches carefully. Authorization or tenant-related data needs correct keys, invalidation, and miss handling. Losing a permission cache should trigger a safe authoritative check, not an automatic grant of access.
Design for misses and rejected writes
A cache miss should invoke a bounded and well-understood recovery path. Avoid a stampede in which many requests regenerate the same expensive value at once. Controlled coalescing, appropriate locking, or another tested mechanism can protect the source system during widespread eviction.
Treat a failed cache write according to the operation’s purpose. Some derived caches can serve an uncached result safely; other state changes cannot continue without recording the value. Do not hide every Redis error behind a generic success response.
If Redis holds sessions, test what happens when session state disappears. A secure reauthentication requirement may be appropriate, while granting default privileges is not. If it holds queue state, review the queue implementation’s guarantees rather than assuming ordinary cache semantics apply.
Measure the policy under representative pressure
In a controlled environment, fill the instance using realistic key sizes, access patterns, and TTL distribution. Observe memory use, evicted and expired key counters, cache hit behavior, write errors, and latency. Read metrics over time rather than treating one cumulative counter as the current rate.
Measure downstream consequences. Eviction may reduce Redis memory while increasing database load and application latency. A policy that appears efficient in isolation can worsen the service when misses are expensive or concentrated on the same records.
Include recovery after a restart or a cold cache. The application should remain within safe dependency limits when few values are available, not only when a warm cache serves almost every request. Bound test traffic and avoid destructive experiments on production data.
A mixed-workload warning
Imagine one Redis instance stores both product-page caches and login sessions. An allkeys eviction policy may remove either under pressure. The page cache can be regenerated, but session loss affects users and may expose assumptions in authentication code.
The review should decide whether to separate the workloads, change the application’s loss handling, and reserve appropriate memory. Merely switching to a volatile policy is insufficient if both families expire or if nonexpiring state consumes most capacity.
Keep a runbook explaining policy intent, key families, sizing assumptions, useful metrics, and actions for persistent errors. Capacity changes should be reviewed alongside application behavior so the system does not drift from its documented loss model.
Frequently asked questions
Does maxmemory cap every byte used by Redis?
No. Review the deployed configuration’s overhead and excluded-memory considerations. Size the host or container with suitable headroom.
Is noeviction always safer?
Not automatically. It changes the failure mode from removal to potential write rejection. Safety depends on whether the application handles that state correctly.
Where can I verify policy details?
Read the Redis key eviction documentation. For access and network boundaries around the instance, see our Redis security guide.
