A Redis cache configured with `maxmemory-policy allkeys-lru` holds a tenth of the working set under realistic skewed traffic. A teammate suggests switching to `allkeys-lfu` to improve the hit ratio. Would that help, and what's actually being tuned when the eviction policy changes?

For a stable, skewed popularity distribution — a few products get most of the traffic, most get very little — LFU is usually a better predictor of what's actually worth keeping than LRU, because LRU only knows what was touched recently, and an unpopular item requested once looks exactly as "recently used" as a genuinely popular one right after either is accessed. The lesson's own experiment found LFU beating LRU by about three points of hit ratio (62.4% versus 59.5%) under a Zipf-skewed workload with a tenth of the data cached — a real but modest gain, translating to several thousand fewer database queries out of 200,000 requests. But eviction policy is tuning the hit ratio at a fixed memory size; if the real problem is that only a tenth of the data fits at all, checking whether more memory actually moves the ratio is usually the higher-leverage question before switching policies.