A cache eviction policy is a predetermined algorithm that determines which items to remove from a cache when it reaches its capacity limit to make space for new entries. It is a critical component of memory management in computing systems, directly impacting performance by balancing hit rates against storage constraints. Common deterministic policies include Least Recently Used (LRU) and Least Frequently Used (LFU), while adaptive algorithms like Adaptive Replacement Cache (ARC) dynamically tune their behavior based on workload.
Glossary
Cache Eviction Policy

What is a Cache Eviction Policy?
A core algorithm in memory and storage systems that determines which items to remove when capacity is reached.
The choice of eviction policy is a fundamental engineering trade-off between recency, frequency, and cost of recomputation. In agentic systems, these policies govern short-term memory caches, managing the active context within a limited context window. Effective policy selection minimizes cache misses and ensures that the most valuable data for ongoing reasoning remains readily accessible, which is essential for maintaining agent performance over extended operational timeframes.
Key Eviction Algorithms
These are the core algorithmic strategies used to determine which items are removed from a cache when it reaches capacity. The choice of policy directly impacts cache hit rates, latency, and overall system performance.
Least Recently Used (LRU)
Least Recently Used (LRU) evicts the item that has not been accessed for the longest time. It operates on the principle of temporal locality, assuming recently used data is likely to be used again.
- Implementation: Typically uses a doubly-linked list and a hash map. On access, the item is moved to the 'most recent' end of the list. The item at the 'least recent' end is evicted.
- Use Case: Excellent for workloads with strong recency patterns, such as web page caches and database buffer pools.
- Weakness: Can be fooled by scans (one-time sequential accesses) that flush the entire cache.
Least Frequently Used (LFU)
Least Frequently Used (LFU) evicts the item with the lowest count of access requests. It prioritizes frequency of use over recency.
- Implementation: Maintains a frequency count for each item. Requires more metadata (counters) than LRU and must handle aging to prevent stale, high-count items from permanently occupying the cache.
- Use Case: Ideal for workloads with stable, popular reference patterns, like caching popular product data or media assets.
- Weakness: Susceptible to cache pollution from a burst of requests to a new item that is never accessed again, as its high initial count protects it.
First-In, First-Out (FIFO)
First-In, First-Out (FIFO) evicts the item that has been in the cache the longest, regardless of how often or recently it was accessed. It treats the cache as a simple queue.
- Implementation: Low overhead. New entries are added to the tail of a queue; eviction occurs at the head.
- Use Case: Simple, predictable behavior for sequential or streaming data where access patterns are uniform.
- Weakness: Poor performance for most dynamic workloads because it ignores both recency and frequency, often evicting hot data.
Random Replacement (RR)
Random Replacement (RR) selects a candidate item for eviction at random from the cache.
- Implementation: Very low computational cost. Requires a pseudo-random number generator and a way to index into the cache (e.g., an array).
- Use Case: Useful as a simple baseline or in adversarial scenarios where other policies' predictable access patterns can be exploited to force worst-case performance (cache thrashing).
- Weakness: Unpredictable and generally yields lower hit rates than LRU or LFU for common workloads, but avoids systematic worst-case behavior.
Adaptive Replacement Cache (ARC)
Adaptive Replacement Cache (ARC) is a sophisticated, self-tuning algorithm that dynamically balances between LRU (recency) and LFU (frequency).
- Implementation: Maintains two LRU lists: T1 for recent entries and T2 for frequent entries. A target parameter
padaptively sizes these lists based on workload. It learns and adjusts to the actual access pattern. - Use Case: High-performance database systems (e.g., IBM DB2, ZFS) and file caches where workloads are mixed or unpredictable.
- Weakness: Higher memory overhead for metadata and more complex implementation than basic LRU/LFU.
Time-To-Live (TTL) Expiration
Time-To-Live (TTL) is not a capacity-based eviction policy but a time-based expiration mechanism. Each cache entry has an absolute or relative timestamp after which it is considered stale and evicted on next access or by a background cleaner.
- Implementation: Requires storing a timestamp per entry and a periodic or lazy process to purge expired items.
- Use Case: Critical for data with inherent freshness requirements, such as API rate limit counters, session data, news feeds, or any data sourced from a mutable backend.
- Interaction: Often used in conjunction with capacity policies (e.g., LRU). An item may be evicted because it expired (TTL) or because the cache was full (LRU).
Eviction Policy Comparison
A technical comparison of common cache eviction algorithms, detailing their operational mechanics, performance characteristics, and ideal use cases for agentic memory systems.
| Policy / Feature | Least Recently Used (LRU) | Least Frequently Used (LFU) | Time-To-Live (TTL) | Adaptive Replacement Cache (ARC) |
|---|---|---|---|---|
Core Eviction Logic | Removes the item unused for the longest time | Removes the item with the lowest access count | Removes items whose pre-set expiration timestamp has passed | Dynamically balances between LRU and LFU using two adaptive lists |
Data Structure Complexity | Hash Map + Doubly Linked List (O(1) ops) | Hash Map + Min-Heap or Counter (O(log n) ops) | Hash Map + Priority Queue (O(log n) for expiry check) | Two LRU lists (Recent & Frequent) + Ghost lists (O(1) ops) |
Adapts to Pattern Shifts | Moderate (reacts to recent changes) | Poor (frequency counts become stale) | None (time-based only) | Excellent (self-tuning based on workload) |
Resistant to Scan/One-Time Accesses | Poor (scan pollutes cache) | Excellent (one-time accesses evicted quickly) | Variable (depends on TTL setting) | Good (protects frequent list from scans) |
Memory Overhead | Low (2 pointers per item) | Medium-High (counters, heap indices) | Low (timestamp per item) | High (maintains 4 lists: L1, L2, ghosts for L1 & L2) |
Implementation Prevalence | Extremely High (default in many systems) | High | Very High (often combined with other policies) | Medium (specialized, high-performance systems) |
Ideal Workload Pattern | Locality of reference (temporal locality) | Skewed, stable popularity (Zipfian distribution) | Time-sensitive data, session caches, rate limiting | Mixed or unpredictable access patterns |
Worst-Case Scenario | Cyclic sequential access exceeding cache size | Sudden burst of popularity for old items | Poor TTL guess leads to premature eviction or bloating | Small cache sizes where overhead dominates |
Frequently Asked Questions
Cache eviction policies are critical algorithms that determine which items to remove from a finite cache to make space for new entries, directly impacting system performance and hit rates. These FAQs cover the core policies, their trade-offs, and their application in modern agentic memory systems.
A cache eviction policy is a predetermined algorithm that determines which items to remove from a cache when it reaches its capacity limit to make space for new entries. It works by continuously monitoring cache access patterns—such as recency, frequency, or size—and applying a heuristic to select the 'best' candidate for removal when space is needed. The core mechanism involves maintaining metadata (like access timestamps or counters) for each cached item and executing a comparison function (e.g., find oldest timestamp) upon a cache miss that requires insertion into a full cache. In agentic systems, this governs which memories (e.g., past interactions, tool call results) are retained for immediate context, directly influencing the agent's operational continuity and reasoning coherence.
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
Related Terms
Cache eviction policies are part of a broader engineering discipline focused on managing finite memory resources. The following terms detail specific algorithms, related problems, and system-level mechanisms that interact with eviction strategies.
Least Recently Used (LRU)
Least Recently Used (LRU) is the canonical cache eviction algorithm that removes the item that has not been accessed for the longest period. It operates on the principle of temporal locality, assuming recently used data is likely to be used again.
- Implementation: Often uses a doubly-linked list and a hash map for O(1) access and movement.
- Weakness: Can be exploited by scans (one-time sequential access of many items), which flush the entire cache.
- Variants: LRU-K considers the time of the K-th-to-last access for better resistance to scans.
Least Frequently Used (LFU)
Least Frequently Used (LFU) is a cache eviction algorithm that removes the item with the lowest count of access requests. It prioritizes popularity over recency.
- Implementation: Requires maintaining and sorting access counts, often with a min-heap or complex data structures.
- Challenge: Cache pollution from items with a high initial count that are never accessed again.
- Modern Use: Common in CDN and web caching where long-term popularity is a strong predictor.
Time-To-Live (TTL)
Time-To-Live (TTL) is a time-based expiration mechanism that sets a deadline on cached data, after which the item is considered stale. It is often used in conjunction with, or as a primary driver for, eviction.
- Primary Use: Ensures data freshness and consistency by bounding how long stale data can persist.
- Implementation: Each cache entry stores an expiration timestamp. A background sweeper or lazy evaluation removes expired items.
- Example: DNS records and API response caches heavily rely on TTL for propagation and consistency.
Adaptive Replacement Cache (ARC)
Adaptive Replacement Cache (ARC) is a self-tuning, adaptive policy that dynamically balances between recency (LRU) and frequency (LFU). It uses two LRU lists: one for recent entries (T1) and one for frequent entries (T2), with adaptive sizes.
- Mechanism: Monitors hits in the lists to decide whether to favor recency or frequency, resizing T1 and T2 accordingly.
- Advantage: Resists scans better than pure LRU and adapts to changing access patterns without manual tuning.
- Complexity: Higher overhead than LRU but provides robust performance for mixed workloads.
Cache Invalidation
Cache invalidation is the process of marking cached data as obsolete and removing it to ensure consistency when the underlying source data changes. It is a critical problem in system design.
- Strategies: Write-through (update cache and DB simultaneously), write-behind (update cache, queue DB write), and invalidation protocols (e.g., purge messages).
- Challenge: Scalability in distributed caches; maintaining consistency without excessive coordination.
- Quote: Often cited as one of the two hard things in computer science, alongside naming things and off-by-one errors.
Working Set Model
The working set model is a principle in memory management defining the subset of pages or cache entries a process actively needs within a specific time window (Δ). The goal of a cache is to hold the current working set.
- Principle: If the cache can contain the entire working set, hit rate is high. If not, thrashing occurs.
- Application: Informs the sizing of caches and helps analyze the performance of eviction policies.
- Relation to Eviction: Optimal eviction would only remove items not in the working set, which is theoretically impossible without future knowledge.

About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us