# Requirement change

Ops lost some data they cared about. An entry got evicted from the cache under load and, because
the cache was the only place it lived, it was just gone — the on-call engineer had to rebuild it
from a slow path that took several minutes, during an incident where several minutes mattered.

**Whenever the cache pushes an entry out to make room for another, write it through to a durable
backing store first, so evicting from the cache never means losing the value.** And while we're
there: if somebody asks the cache for a key it doesn't currently have, and that key is sitting in
the backing store, don't just report a miss — pull it back in and serve it as a hit, the way a
cache in front of a real datastore normally would.

- The backing store is provided by whoever constructs the cache — it isn't something the cache
  invents or manages the lifecycle of.
- A plain `put` with no backing store configured behaves exactly as it does today.
- A key that's only in the backing store, not currently in the cache, should be treated as present
  when asked directly whether it's there — but don't go pulling it back into the cache just to
  answer that question. Only an actual read should do that.
