Caching medium
An analytics job performs a full table scan, reading every row in the DB once. Why is a standard LRU cache policy bad for this workload?
- A It causes 'Cache Pollution': The one-time-use items flood the cache, evicting the frequently accessed 'hot' data that the application relies on.
- B LRU is an O(N) complexity algorithm and the linear scan overhead becomes too computationally expensive for the primary CPU thread.
- C The full table scan generates massive write locks at the database layer that prevent the cache from performing its background refresh operations.
- D Standard LRU policies are strictly optimized for write-heavy workloads and will fail to accurately track the recency of read-only scan operations.
Answer: A. It causes 'Cache Pollution': The one-time-use items flood the cache, evicting the frequently accessed 'hot' data that the application relies on.
Standard **LRU** assumes that 'recently used' equals 'valuable'. A full table scan (reading every record once) updates the 'recency' of rarely used items, pushing truly popular items out of the cache. This is called **Cache Pollution**. Advanced policies like **ARC** or **TinyLFU** resist this by tracking frequency or maintaining a separate 'probationary' segment.
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- In the Cache-Aside pattern, what happens when the application requests data that is missing from the cache (a 'Cache Miss')?
- Why use a centralized Distributed Cache (like a Redis Cluster) over local in-memory caches on each web server?
- Setting a short TTL (e.g., 60 seconds) on a cached object helps to:
- What is the primary architectural goal of introducing a cache into a system?
- Most caching systems rely on the principle of 'Temporal Locality', which states:
- Your cache uses an LRU (Least Recently Used) eviction policy. When the cache is full, which item is removed?