Skip to content

Cache Eviction Rule

A capacity-triggered removal rule — instantiates Layer Decay and Expiration Management

Decides which layer to drop the instant a fixed-capacity fast tier fills up, using an access-recency or -frequency rule so the least-useful resident makes room for the newest.

Some pileups are governed by a hard ceiling, not a calendar. Cache Eviction Rule is the disposition mechanism for a fixed-capacity fast tier: the moment a new layer must be admitted and there is no room, the rule names a victim to evict on the spot. Its distinguishing feature is that it is triggered by capacity pressure, not by age or policy — nothing is "too old"; something simply has to go now so the newest arrival can be kept hot. It reads the tier's access state — who was touched recently, who often — and evicts the resident least likely to be needed next. This is online, continuous, and reversible only by re-fetching from a slower tier; it is the sharpest, most immediate form of layer disposition in the set.

Example

A CDN edge node has room for the 50,000 hottest objects; behind it sits origin storage holding everything. A request arrives for a video segment not in the edge cache. The node must admit it, so its Cache Eviction Rule — say least-recently-used (LRU) — evicts whichever cached object has gone longest untouched to free a slot. Under a flash crowd for a live event, the rule keeps the event's segments resident and lets yesterday's cold catalogue drain out to origin, holding the edge's hit ratio high without any human deciding what "expired." Swap the rule to least-frequently-used (LFU) and behaviour shifts: a rarely-but-steadily requested asset survives a traffic spike that LRU would have flushed. Same capacity, same tier — a different eviction rule, a different set of survivors.

How it works

The rule's substance is entirely in how it picks the victim under pressure:

  • Watch the access state of each resident — recency (LRU), frequency (LFU), or a blend — as the proxy for "will this be needed again soon."
  • On admission with no free slot, evict the lowest-ranked resident by that proxy; the demoted layer isn't destroyed, it falls back to the colder tier it can be re-fetched from.
  • Optionally honour a priority/pin override so designated layers resist eviction regardless of access.
  • Optimise for a tier-level objective — hit ratio, tail latency — rather than for any single layer's fate.

Tuning parameters

  • Eviction policy — LRU, LFU, FIFO, or a weighted hybrid. Recency adapts fast to shifting demand; frequency protects steady low-volume regulars; the choice is a bet on what your access pattern looks like.
  • Capacity budget — how large the hot tier is. A bigger budget evicts less and lifts hit ratio, at direct storage cost; this dial sets how often the rule even fires.
  • Admission control — whether every miss is cached or only ones likely to recur, to stop one-hit scans from evicting genuinely hot residents (cache pollution).
  • Pinning / priority tiers — which layers are exempt from eviction, trading guaranteed residency for less room to adapt.
  • Recency vs. frequency weighting — in a hybrid, how much each counts, tuning between bursty and steady workloads.

When it helps, and when it misleads

Its strength is that it manages a hard resource ceiling automatically and instantly, with no scheduling and no per-layer decision — it keeps the useful stuff fast and lets the rest drain, sustaining throughput under pressure it never has to forecast.

Its weakness is that eviction is a bet on the future from the past, and the bet can be wrong. LRU is fooled by a large one-pass scan that evicts the true working set (cache pollution); LFU can ossify, protecting once-popular layers long after they've gone cold. Because eviction optimises a tier metric, it will happily drop a layer that is rarely accessed but individually critical — access frequency is not importance. And it is emphatically not a deletion or retention mechanism: an evicted layer must still exist safely in a colder tier, so treating eviction as disposal is a category error that loses data. The discipline is to keep eviction confined to reconstructible caches and to lean on admission control and pinning where the access signal alone misleads.[1]

How it implements the components

Cache Eviction Rule realises the capacity-and-access side of the archetype — disposition driven by a resource ceiling rather than a clock:

  • hot_warm_cold_access_state — recency/frequency of access is the signal it ranks on; the rule reads and updates each layer's hot-vs-cold standing.
  • resource_budget_and_storage_tier — the fixed tier capacity is the constraint that triggers it; the rule exists to keep the tier inside its budget.

It does not relocate or compact layers on a schedule (that's the Lifecycle Storage Tiering Policy) and it does not permanently delete anything or record why — an evicted layer survives in a colder tier; deletion and its audit belong to Soft-Delete Quarantine Window and Tombstone or Deletion Marker.

Notes

The rule is safe only because eviction is not deletion: it assumes a colder tier from which any evicted layer can be re-fetched. Point a cache eviction rule at data that exists nowhere else and it becomes a silent data-loss engine. Where capacity pressure meets genuinely unique layers, the decision belongs to value scoring and a safe-delete gate, not to an eviction rule.

References

[1] No online eviction rule can be optimal in general — the theoretical optimum (Bélády's algorithm) requires knowing future accesses, which is why real rules are heuristics that approximate it and can be defeated by adversarial access patterns. The concept is invoked as-is, not as a cited result. ↩