Redis Caching Eviction Strategies and Selection

The Dilemma of Finite Memory: Understanding Redis Eviction

In the realm of high-performance computing, Redis stands out due to its incredible speed, a direct result of its in-memory architecture. However, this speed comes with a fundamental constraint: memory is a finite resource. Unlike disk-based databases that can scale to terabytes with relatively low cost, Redis is strictly bounded by the physical RAM available to the host system.

As your dataset grows, you will inevitably encounter the maxmemory threshold—the limit configured to prevent the system from consuming all available host memory and triggering an Out-Of-Memory (OOM) killer. When this limit is reached, Redis faces a critical architectural decision: should it reject new incoming data, or should it proactively sacrifice existing data to make room for the new? This decision-making process is governed by Eviction Policies.

Clearing the Confusion: Expiration vs. Eviction

Before diving into specific strategies, it is imperative to distinguish between two terms that are frequently conflated by developers: Expiration and Eviction.

• Expiration (TTL-based): This is a time-driven mechanism. When you set a Time-To-Live (TTL) on a key, you are telling Redis, "This data is only valid for $X$ seconds." Once that time elapses, the key becomes invalid. Redis cleans these up through a combination of passive deletion (deleting a key when it is accessed and found to be expired) and active deletion (periodically scanning and sampling keys to remove expired ones).
• Eviction (Capacity-based): This is a resource-driven mechanism. Eviction occurs when the system is under memory pressure. Regardless of whether a key has an expiration timer or not, Redis will forcibly remove certain keys to stay within the maxmemory limit.

In short: Expiration is about data freshness, while Eviction is about memory availability.

The Taxonomy of Redis Eviction Policies

Redis provides a versatile suite of eviction policies, which can be categorized based on two dimensions: the scope of the target keys (whether they have a TTL) and the algorithm used to select the victim.

1. The "Safety First" Approach: No Eviction

• noeviction: This is the default behavior. When the memory limit is reached, Redis refuses to perform any operation that results in more memory being used (such as SET or LPUSH), returning an error instead. This is the preferred setting when Redis is being used as a primary persistent database, where data loss is unacceptable.

2. The "Surgical" Approach: Volatile Policies

These policies are "TTL-aware." They only consider keys that have an explicit expiration set. This allows you to protect "permanent" data (like configuration settings) while allowing the cache to churn.

• volatile-lru: Evicts the Least Recently Used keys among those with a TTL.
• volatile-lfu: Evicts the Least Frequently Used keys among those with a TTL.
• volatile-random: Picks keys with a TTL at random for eviction.
• volatile-ttl: Evicts the keys with the shortest remaining time-to-live.

3. The "Blanket" Approach: Allkeys Policies

These policies ignore whether a key has a TTL or not; they treat the entire dataset as a pool of candidates for eviction. This is typical for pure caching scenarios.

• allkeys-lru: Evicts the Least Recently Used keys from the entire dataset.
• allkeys-lfu: Evicts the Least Frequently Used keys from the entire dataset.
• allkeys-random: Picks keys from the entire dataset at random.

The Algorithmic Battle: LRU vs. LFU

The most critical technical decision for an engineer lies in choosing between LRU and LFU. These two algorithms represent different philosophies of "value."

LRU (Least Recently Used): The Principle of Recency

LRU operates on the assumption of temporal locality: if a piece of data was accessed recently, it is highly likely to be accessed again in the near future.

It is important to note that Redis does not implement a "perfect" LRU. Maintaining a strictly ordered doubly-linked list of every single key would incur massive CPU and memory overhead. Instead, Redis uses an Approximate LRU algorithm. It selects a small sample of keys and evicts the oldest one among that sample. This provides a high-performance approximation that is "good enough" for most production workloads.

LFU (Least Frequently Used): The Principle of Frequency

LFU shifts the focus from when a key was last accessed to how often it is accessed. It tracks access counts to identify "hot" keys.

LFU solves a classic weakness of LRU known as cache pollution. Imagine a scenario where a massive batch job accesses a large set of keys once (e.g., a daily report). In an LRU system, these keys would suddenly appear "fresh" and push out actually useful, frequently accessed data. LFU avoids this because, despite being recently accessed, those keys have a very low access frequency. Redis implements LFU with a decay mechanism, ensuring that old "hot" keys eventually lose their status if they are no longer being actively used.

Strategic Selection: A Decision Framework

Choosing the right policy is not a matter of finding the "best" algorithm, but finding the one that matches your access patterns.

1. Is your Redis a Database?
   If the data in Redis is your "source of truth" and cannot be lost, use noeviction. You must rely on proactive monitoring and capacity planning (scaling up memory) rather than automated eviction.

2. Is your Redis a Pure Cache?

   • If your workload exhibits temporal locality (e.g., a user session where data is accessed intensely for a short window), allkeys-lru is your best bet.
   • If your workload is driven by consistent hot spots (e.g., a celebrity profile on a social network that is always high-traffic), allkeys-lfu will yield a higher hit rate.

3. Do you have a mix of "Transient" and "Static" data?
   If you store both short-lived cache items and long-lived configuration data in the same instance, use the volatile-* series. This ensures that your critical, non-expiring data remains untouched during memory pressure.

Conclusion: The Engineering Impact

Mastering Redis eviction is more than just a theoretical exercise; it is a pillar of system stability and cost optimization.

A poorly chosen policy can lead to catastrophic write failures (OOM errors) or a plummeting cache hit rate. A low hit rate forces more requests to your backend database, increasing latency and potentially causing a cascading failure across your entire architecture. Conversely, a finely-tuned eviction strategy maximizes your hardware ROI, allowing you to serve massive traffic volumes with minimal memory footprints. In modern distributed systems, understanding these nuances is what separates a functional system from a resilient one.