Cache Eviction Policies: LRU, LFU, FIFO and TTL Tradeoffs
Compare cache eviction policies including LRU, LFU, FIFO, random eviction and TTL-based expiry with hit-rate, memory, and Redis interview tradeoffs.
Quick answer: Cache Eviction Policies: LRU, LFU, FIFO and TTL Tradeoffs
Cache Eviction Policies: LRU, LFU, FIFO and TTL Tradeoffs is covered here as a practical system design concept. Compare cache eviction policies including LRU, LFU, FIFO, random eviction and TTL-based expiry with hit-rate, memory, and Redis interview tradeoffs. Use it to understand the Caching idea, where it appears in production systems, and how to discuss it clearly in interviews.
Focus on the problem being solved, the main design choice, the failure mode, and the tradeoff you would defend in front of a senior engineer. This page is part of the DosiBridge system design knowledge graph, so it links related concepts, interview problems, tradeoffs, and references instead of leaving the topic isolated.
When You Need Cache Eviction Policies
The eviction policy directly affects cache hit rate. A poor policy evicts useful data, causing more cache misses and higher latency. The right policy keeps hot data in cache.
What It Is
Cache eviction policies determine which items to remove when the cache is full and new items need to be stored. Common policies: LRU (Least Recently Used), LFU (Least Frequently Used), FIFO (First In First Out), Random, and TTL-based.
How It Works
Redis supports multiple eviction policies: volatile-lru (LRU among keys with TTL), allkeys-lru (LRU among all keys), volatile-ttl (evict keys closest to expiration), noeviction (return error when full). Choose based on your workload.
LRU is typically implemented with a hash map (O(1) lookup) + doubly linked list (O(1) move to front/remove from back). On access, move the item to the front. On eviction, remove from the back.
The Decision Framework
- LRU (Least Recently Used): Evicts the item that has not been accessed for the longest time. Most common policy. Good for workloads with temporal locality.
- LFU (Least Frequently Used): Evicts the item accessed the fewest times. Better for stable access patterns. But new popular items start with low frequency.
- FIFO: Evicts the oldest item. Simple but ignores access patterns.
- TTL (Time to Live): Items expire after a set time. Prevents stale data. Often combined with LRU.
- W-TinyLFU (Caffeine): Modern policy that combines recency and frequency. Used in Java's Caffeine cache. Near-optimal hit rates.
What the Industry Uses
Redis defaults to noeviction but allkeys-lru is recommended for caches.
Memcached uses LRU eviction within each slab class.
CDNs typically use a combination of LRU and TTL to manage cached content.
Performance and Tradeoffs
- LRU vs LFU: LRU works well for temporal locality; LFU works for stable popularity.
- Simplicity vs Optimality: FIFO is simplest but worst hit rate. W-TinyLFU is near-optimal but complex.
- TTL: Short vs Long: Short TTL keeps data fresh; long TTL maximizes hit rate.
Mistakes Engineers Make
- Using noeviction — causes errors when cache is full instead of gracefully evicting
- Not monitoring eviction rate — high eviction means the cache is too small
- Using FIFO when access patterns have clear locality
Practice These Interview Questions
- What cache eviction policies do you know?
- How is LRU implemented? What is its time complexity?
- When would you use LFU over LRU?
- How does Redis handle cache eviction?
Original DosiBridge notes for Cache Eviction Policies: LRU, LFU, FIFO and TTL Tradeoffs
This section is written specifically for this page, not copied from a general system-design checklist. The useful way to study Cache Eviction Policies: LRU, LFU, FIFO and TTL Tradeoffs is to connect the concept to a read-heavy path where the cache can either protect the database or serve confusing stale data. That framing changes the design discussion from definitions to operating choices.
What makes this topic distinct
- Freshness Window: For Cache Eviction Policies: LRU, LFU, FIFO and TTL Tradeoffs, decide the freshness window before choosing tools; otherwise the design looks clean but fails when cache changes.
- Eviction Pressure: For Cache Eviction Policies: LRU, LFU, FIFO and TTL Tradeoffs, decide the eviction pressure before choosing tools; otherwise the design looks clean but fails when eviction changes.
- Hot Key Behavior: For Cache Eviction Policies: LRU, LFU, FIFO and TTL Tradeoffs, decide the hot-key behavior before choosing tools; otherwise the design looks clean but fails when policies changes.
- Cache Stampede: For Cache Eviction Policies: LRU, LFU, FIFO and TTL Tradeoffs, decide the cache stampede before choosing tools; otherwise the design looks clean but fails when cache changes.
- Invalidation Owner: For Cache Eviction Policies: LRU, LFU, FIFO and TTL Tradeoffs, decide the invalidation owner before choosing tools; otherwise the design looks clean but fails when eviction changes.
Production review question
If a team adopts Cache Eviction Policies: LRU, LFU, FIFO and TTL Tradeoffs, what observable signal proves it helped instead of only making the architecture diagram more fashionable?
Practical metric to track
Track cache-policies health as a named dashboard or review item: combine one user-facing metric, one saturation metric, and one correctness metric. For Cache Eviction Policies: LRU, LFU, FIFO and TTL Tradeoffs, this keeps the discussion grounded in behavior that can be measured after deployment instead of generic advice that sounds good in an interview but never gets verified.