Redis Eviction Changes the Meaning of a Missing Key

A missing Redis key may mean it never existed, expired, was deleted or was evicted under memory pressure. Applications that treat every miss as a harmless cache lookup failure can behave incorrectly when Redis also holds non-reconstructible state.

Choose eviction policy from the meaning of the data, not from a generic recommendation to keep memory usage below a percentage.

The concrete problem

The following observation commands help establish the current memory and eviction state. Use an isolated test instance to change maxmemory or policy. Provider-managed services can expose a different control surface.

Figure: Memory reaches configured limit → Policy selects eviction or error → Application interprets missing state.

A worked example

CONFIG GET maxmemory
CONFIG GET maxmemory-policy
INFO memory
INFO stats
# Examine used_memory, memory overhead and evicted_keys.
# Observe deltas over a defined window, not only lifetime counters.

Why the behavior matters

allkeys policies may evict any eligible key according to the chosen approximation. volatile policies restrict candidates to keys with expiration, which can create surprising behavior when only some key families have TTLs. noeviction avoids automatic eviction but can reject writes when the memory limit is reached; it is not a promise that the application continues normally.

Memory accounting also includes overhead and buffers, and the memory relevant to eviction is not identical to a simplistic sum of serialized payload sizes. Measure actual usage under realistic key counts, value sizes and client activity. A million tiny keys can have a different footprint from a few large values containing the same total application data.

Failure modes and design tradeoffs

Do not place critical idempotency keys, job state or security controls in an eviction domain without deciding what premature disappearance means. Splitting cache and authoritative workloads into separate instances can make their failure policies clearer, although it introduces operational cost.

A rising hit rate does not compensate for write errors or lost workflow state. Monitor evictions, rejected writes, keyspace changes and source load together. Alerts need time windows and workload context; a lifetime evicted_keys total alone cannot identify a current incident.

What to verify before adoption

Fill a disposable instance with representative key families until the configured limit is reached. Observe which keys disappear, whether writes fail and how the application recovers. Repeat with TTL and non-TTL keys. Confirm that the measured failure matches the documented cache or state-store contract before adopting a policy.

Primary reference

• Redis documentation. Verify the exact deployed version and driver behavior before using the example in a production runbook.