Caching

Some work is slow, like a database query. Doing it again for every user who asks for the same data is a waste.

Why cache

A cache keeps copies of often-used data in fast storage, usually memory. The app reads the copy and skips the slow work. The real data still lives in the database, so losing the cache loses nothing for good. A cache only helps when the same data is read again and again.

Hits and misses

A hit means the data was in the cache. A miss means it was not, so the app must go to the database. The hit rate is hits / (hits + misses). With 90 hits and 10 misses, the hit rate is 90%, and only 10 reads reach the database. A new, empty cache is cold: almost every read misses at first.

Cache-aside

The most common way to use a cache:

1. The app checks the cache.
2. On a hit, it returns the cached copy.
3. On a miss, it reads the database.
4. It puts the result in the cache, so the next read is a hit.

The app fills the cache, not the database.

Stale data

When the database changes, the cached copy can go out of date. That copy is stale. A time to live (TTL) makes an entry expire after a set time, so data is never older than the TTL. It limits staleness but does not stop it. To fix it sooner, delete the cached entry every time the data is written.

Eviction

When a cache is full, it must evict (remove) an entry to add a new one. LRU (least recently used) evicts the entry used longest ago, since recent data is likely to be used again.

Remember

• Hit rate = hits / (hits + misses).
• Cache-aside: check the cache, then the database, then fill the cache.
• A TTL limits staleness; it does not prevent it.
• LRU evicts the entry used longest ago, not the one added first.