Eviction policies (LRU, LFU, random) in Redis - Time & Space Complexity
When Redis runs out of memory, it removes some data using eviction policies.
We want to know how the time to pick which data to remove grows as the data size grows.
Analyze the time complexity of eviction policy operations in Redis.
// Example: LRU eviction check
if (memory_limit_reached) {
key_to_evict = find_least_recently_used_key();
delete_key(key_to_evict);
}
// For LFU, Redis updates usage counters and evicts least frequently used keys
// Random eviction picks a random key to delete
This code decides which key to remove when memory is full, using different policies.
Look at what Redis does repeatedly to find keys to evict.
- Primary operation: Finding a key to evict based on policy (LRU, LFU, or random).
- How many times: Once per eviction event, but may scan or update metadata for many keys over time.
As the number of keys grows, how much work does eviction take?
| Input Size (n keys) | Approx. Operations |
|---|---|
| 10 | Few operations, quick eviction |
| 100 | Still fast, small overhead per eviction |
| 1000 | Operations grow slowly, eviction still efficient |
Pattern observation: Redis uses smart data structures so eviction time grows slowly, not linearly with keys.
Time Complexity: O(1)
This means eviction takes about the same time no matter how many keys are stored.
[X] Wrong: "Eviction time grows a lot as the database gets bigger because it must check every key."
[OK] Correct: Redis keeps track of usage info efficiently, so it does not scan all keys each time.
Understanding how eviction policies work and their time cost shows you know how Redis handles memory smartly.
What if Redis used a simple list to track usage instead of efficient data structures? How would the time complexity change?
Practice
Solution
Step 1: Understand eviction policies in Redis
Redis uses eviction policies to free memory when it is full by removing keys based on certain rules.Step 2: Identify the policy that removes least recently used keys
LRU stands for Least Recently Used, which means it removes keys that have not been accessed for the longest time.Final Answer:
LRU (Least Recently Used) -> Option AQuick Check:
Eviction policy removing least recently used keys = LRU [OK]
- Confusing LRU with LFU
- Thinking random eviction is based on usage
- Assuming no eviction means keys are removed
Solution
Step 1: Recall Redis maxmemory-policy options
Redis uses the 'maxmemory-policy' directive to set eviction behavior, with options like 'allkeys-lfu' for LFU eviction.Step 2: Identify the correct syntax for LFU eviction
The correct directive for LFU eviction on all keys is 'maxmemory-policy allkeys-lfu'.Final Answer:
maxmemory-policy allkeys-lfu -> Option AQuick Check:
LFU eviction config = maxmemory-policy allkeys-lfu [OK]
- Using 'random-eviction' instead of LFU
- Confusing 'volatile-lru' with LFU
- Missing 'maxmemory-policy' keyword
maxmemory-policy allkeys-lru and memory is full, what happens when a new key is added?Solution
Step 1: Understand the 'allkeys-lru' eviction policy
This policy evicts the least recently used key among all keys when memory is full.Step 2: Predict behavior when adding a new key
When memory is full, Redis removes the least recently used key to free space for the new key.Final Answer:
The least recently used key is evicted to make space -> Option CQuick Check:
allkeys-lru evicts least recently used key [OK]
- Confusing LRU with LFU eviction
- Thinking random eviction applies here
- Assuming new keys are rejected automatically
maxmemory-policy volatile-lfu but notice keys without expiration are never evicted. What is the likely cause?Solution
Step 1: Understand volatile-lfu eviction policy
Volatile policies only evict keys that have an expiration set (TTL).Step 2: Analyze why keys without expiration remain
Since keys without expiration are not eligible, they are never evicted under volatile-lfu.Final Answer:
Only keys with expiration are considered for eviction in volatile-lfu -> Option BQuick Check:
Volatile policies evict only expiring keys [OK]
- Assuming LFU ignores expiration
- Thinking random eviction applies here
- Believing keys without expiration are evicted first
Solution
Step 1: Understand eviction policy prefixes
'allkeys-' applies to all keys; 'volatile-' applies only to keys with expiration.Step 2: Identify random eviction among volatile keys
'volatile-random' evicts keys randomly but only among keys with expiration set.Final Answer:
volatile-random -> Option DQuick Check:
Random eviction on expiring keys = volatile-random [OK]
- Choosing allkeys-random which evicts all keys
- Confusing LFU or LRU with random eviction
- Selecting volatile-lru which is not random
Ready to prove it?
Pass the test and this pattern moves unknown
