LRU vs MRU: Two Ways to Forget
Every cache is a bet that what you touched recently, you'll touch again soon. A cache with a fixed capacity can't keep everything, so on a miss it has to throw something out. The eviction policy is the rule for choosing the victim.
The reflex answer is LRU — evict the least recently used entry, the coldest key that nobody has asked for in the longest time. Its mirror image, MRU, evicts the most recently used entry instead. That sounds perverse until you picture a scan over data larger than the cache: the thing you just read is the thing you're least likely to need again, so keeping it is what pollutes the cache.
The two policies only diverge once the cache is full and a miss forces an
eviction. Watch the same access sequence run under both — the moment E arrives
is where they part ways:
Same accesses, same capacity, different victim. LRU drops B — untouched
longest — and keeps the freshly-promoted A. MRU drops A — the hottest key —
on the theory that a one-off scan shouldn't evict the working set behind it.
Neither is universally right. LRU wins on workloads with temporal locality (most real ones); MRU wins on large sequential or cyclic scans, which is why it shows up in database buffer managers that know they're streaming a big table. The lesson isn't which to pick — it's that "evict the obvious one" hides a choice worth making on purpose.