Remove whatever has not been touched for the longest time.

The idea is simple: recently used items are often used again soon. That makes LRU a useful starting point.

The weakness — and it is severe. LRU is destroyed by a scan: one large pass over data that will not be requested again. A nightly report reading a million products marks all of them “recently used,” pushing out the small hot set that your actual users depend on. The report finishes; your cache is full of things nobody wants; your hit ratio collapses; your database absorbs the difference.

A single batch job can wipe out a perfectly healthy cache. Watch for this.

Where you would use it Almost everywhere, as the default. It is what Redis allkeys-lru gives you, what most application cache libraries do without being asked, and what your CPU does with its own caches. Session data fits it especially well — a user who was active a minute ago is the one most likely to be back. Reach for something else only if you have batch jobs sweeping the cache, or a hot set stable enough for LFU to protect.

Remove whatever has been requested least often, regardless of when.

The logic: popularity is more meaningful than recency. A page requested 10,000 times matters more than one requested once, even if the once was more recent.

Why it can beat LRU: it survives scans. The report's million products each get one access; the front-page item has thousands. LFU keeps the front page and discards the report data — exactly right.

The weaknesses:

• New items look unpopular. Something added a second ago has a count of 1 and is a prime eviction target, even if it is about to become the most popular item on the site. New content struggles to establish itself.
• Old items overstay. Something enormously popular last month keeps a high count long after people stopped wanting it.

Practical implementations use windowed or decaying LFU, counting recent accesses more heavily, which fixes both. If you choose LFU, choose one of these.

Where you would use it When a small, stable set of items takes most of the traffic — the top 1% of products that account for most views, a CDN holding assets that stay popular for months, reference data that barely changes. It is also the right answer when you have a nightly batch job that would otherwise flush an LRU cache. Avoid it where content turns over quickly: news, social feeds, anything where today's popular item was created this morning.

Remove whatever was added earliest, regardless of use.

Simple and cheap — no bookkeeping. It also ignores usage entirely, so it will happily evict your most popular item because it happened to be cached first. Rarely the right choice for a cache; fine for a queue.

Where you would use it Honestly, rarely, and almost never for a general cache. Where it does fit is anywhere insertion order is the point rather than an accident — a fixed-size buffer of recent events, a replay window, a rolling log kept in memory. If every entry has roughly equal value and you want zero bookkeeping, FIFO is defensible. If some entries are more valuable than others, it is the wrong tool.

Remove a randomly chosen item.

This sounds like giving up, and it is not. It requires no bookkeeping at all, which makes it very fast and memory-efficient — LRU must maintain ordering on every single access, and that costs something on every read.

For workloads without a strong recency pattern, random performs surprisingly close to LRU at a fraction of the overhead. Redis offers it deliberately. Do not dismiss it.

Where you would use it Very high-throughput caches where LRU's per-read bookkeeping is a measurable cost, and memory-constrained systems where the ordering structure itself is too expensive to keep. It also does well where access is genuinely uniform and no hot set exists to protect. Redis exposes it as allkeys-random for exactly these cases.