The rule that ignores usefulness

First in, first out evicts whatever went in first, and that is the entire rule. No access tracking, no counters, just a queue.

Recognise why it keeps appearing in textbooks and almost never in production. It is the cheapest to implement and the easiest to explain.

See the problem: insertion order says nothing about usefulness. Your busiest product was cached at nine this morning and read four thousand times since, and it leaves before something added at noon and never touched.

As throwing away the one piece of information that matters.

Consider random eviction, the other one you will meet, and it is genuinely better than it sounds. Pick a victim at random and you get no scan vulnerability, no bookkeeping, and performance surprisingly close to recency ordering on many workloads.

Redis offers it, and that Memcached's own recency ordering is itself an approximation, because maintaining an exact order costs more than the accuracy is worth.

Say all of that in one sentence if it comes up in an interview, then move on. First in, first out is a reasonable answer about implementing a bounded queue and a poor answer about caching.

Keep the useful version of this knowledge, meaning why recency won, rather than the ability to recite the alternatives.

the shape of it

FIFO knows when an entry arrived and nothing about whether anyone wants it.

the policies in one place

Java

# What people actually run
maxmemory-policy allkeys-lru     # the default answer
maxmemory-policy allkeys-lfu     # skewed traffic, or scans

# Better than it sounds: no bookkeeping, no scan weakness
maxmemory-policy allkeys-random

# Refuse new writes instead of evicting. For a cache this is
# usually wrong; for a store you are treating as durable it is
# the only safe setting.
maxmemory-policy noeviction

Worked example

The one place Arjun shipped FIFO on purpose was not a cache. His image pipeline held the last 500 uploads in memory so a retry could find the bytes without going back to object storage, and a retry always arrived within minutes of the upload.

Insertion order was exactly the right rule there, because the value of an entry really did decay with age and nothing was read twice. An ArrayDeque and a size check did the job in six lines.

That is the shape FIFO fits: a buffer of recent things, not a cache of popular ones.

FIFO, Random, and Why Nobody Picks Them

The rule that ignores usefulness

Worked example