Caching

Cache-aside, invalidation, stampedes and the local-versus-distributed decision — including the cases where a cache adds a consistency problem and buys nothing.

Caching in Backends

A cache trades correctness-in-time for work avoided; everything else in this module is about controlling that trade.

Q · What does a cache actually buy a backend, and what does it cost that a faster query would not?

Cache-Aside

Read the cache, miss, read the database, write the cache — and the four things that go wrong in those four steps.

Q · What is the standard read-through pattern, and where exactly does it leak?

Cache Invalidation

The database changed. How does the cache find out? Four answers, each with a different failure when it does not.

Q · When the underlying data changes, how does the cached copy learn about it — and what happens when that message is lost?

TTL and Expiry

A TTL is a staleness budget written as a number, plus the only invalidation mechanism that cannot fail.

Q · How long should an entry live, and why is a round number almost always the wrong answer?

Cache Stampede

One popular key expires, every in-flight request misses at the same instant, and all of them run the same expensive query at once.

Q · A single key expires and the database falls over. How does one missing entry become an outage?

Local vs Distributed Cache

In-process is faster and per-instance; shared is consistent and one more thing that can be down. The choice is about invalidation, not speed.

Q · Should the cache live inside the process or in a shared store, and what does each choice do to correctness?

When Not to Cache

A cache buys you a consistency problem and an availability dependency. Sometimes it does not buy anything back.

Q · When is adding a cache the wrong answer, and what should be tried first?