Skip to content
About
Main content

Every access stream is three streams

Take any real trace and split it into three components:

ComponentWhat predicts reuseWhat it demands
Stationary popularity: some items are simply hotter, and stay hotfrequencykeep frequent items; use an
Bursty locality: an item is hot for a window and then dead (a session, a job's , a dashboard refresh cycle)recencykeep recent items; promote fast
One-shot traffic: scans, backfills, monotonic IDs, each item touched oncenothing, because there is no reuserefuse to admit

reads only the second signal (recency). LFU reads only the first (frequency). Neither defends against the third. One sequential scan of a table larger than the evicts the whole resident set and replaces it with items that will never be requested again.

LRU's true worst case is a cyclic scan slightly larger than the cache. With 101 items scanned in a loop through an LRU cache of 100, each item is evicted just before it is needed again, so the is exactly zero. Random eviction on the same loop still delivers about 98%.

This derives the architecture of good caches before we name it: a policy must have at least as many components as the workload has components. You need a recency region, a frequency region, and an admission decision. That is exactly the shape of (a small LRU "window" for bursts, a large frequency-governed main region, and a sketch-based admission test between them). The Caffeine cache library later added adaptive resizing of the window, because the mix of the three components drifts during the day. The policy is not clever. It is structurally matched to a three-component stream.

A claim you can test: measure the three fractions for a workload and you can predict which policy family will win without running any of them. (A lab at the end of this mechanism does this.)

In one sentence: three streams (stationary, bursty, one-shot), and a policy needs one component per stream plus a door for the third.