Diagnosing high Redis eviction and cache misses

WHAT THIS TESTS The interviewer wants a measured diagnostic process for Redis under memory pressure, plus real knowledge of eviction policies and the commands that expose the problem.

A GOOD ANSWER COVERS Start with data. Run INFO memory to read used_memory, maxmemory, and mem_fragmentation_ratio, and INFO stats for evicted_keys and keyspace_hits versus keyspace_misses to quantify the eviction and miss rate. Determine the real cause. If used_memory is near maxmemory, you genuinely have too much data for the budget, so look at value sizes, missing TTLs, and whether you are caching things you should not. If mem_fragmentation_ratio is well above one, the OS has given Redis more memory than it can pack, so consider activedefrag or a restart. Then revisit the eviction policy: allkeys-lru evicts least-recently-used keys and suits recency-driven workloads, while allkeys-lfu evicts least-frequently-used keys and is better when a hot subset is accessed repeatedly but not constantly, since LRU can wrongly evict a popular key after a burst of one-off scans. Use volatile policies only if every cacheable key has a TTL.

COMMON WRONG ANSWERS Just raising maxmemory, which delays the problem and costs money. Ignoring fragmentation and concluding you need more RAM. Leaving keys without TTLs so cold data lingers. Assuming LRU is always correct.

LIKELY FOLLOW-UPS When would noeviction be appropriate? How do big keys or unbounded data structures cause pressure? How does TTL randomization prevent eviction stampedes?

ONE CONCRETE EXAMPLE INFO shows evicted_keys climbing and used_memory pinned at maxmemory while a fragmentation ratio of 1.6 wastes space. A nightly analytics scan touches millions of keys once, and under allkeys-lru it evicts the genuinely hot product keys. Switching to allkeys-lfu and enabling active defragmentation restores hit rate without buying more memory.