How do you decide what to cache and for how long (TTL)?

Question

Accepted Answer

Cache data that is **expensive to produce, read frequently, and changes rarely** — that's where caching pays off most. The **TTL** (time to live) is a trade-off between **freshness** (how current the data must be) and **staleness tolerance** (how wrong it can be for how long).

## What to cache

A good cache candidate scores high on all three:

- **Expensive** — heavy DB joins, aggregations, external API calls, rendered HTML.
- **Frequently read** — hot keys hit by many requests amortize the cost.
- **Rarely changing** — or where slight staleness is acceptable.

Don't cache cheap-to-compute, write-heavy, or per-user-secret data whose freshness must be exact (e.g. account balances at the moment of a transaction).

## Choosing the TTL

```text
Staleness tolerance → TTL:
  config / static reference data   → long  (hours to days)
  product listings, article body   → medium (minutes)
  prices, stock, leaderboards      → short  (seconds)
  must always be exact             → don't cache, or use explicit invalidation
```

For correctness on data that changes unpredictably, combine a TTL with **explicit invalidation**: write-through or delete-on-write so the cache is busted the moment the source changes, instead of waiting for expiry.

```text
on update(record):
  db.save(record)
  cache.delete(key(record))   // invalidate now, don't serve stale until TTL
```

## The signal: hit ratio

```text
hit ratio = hits / (hits + misses)
  high (>90%) → cache is doing its job
  low         → TTL too short, keys too granular, or data not cacheable
```

Watch the **cache hit ratio** to tune TTLs: a low ratio means you're barely caching; a high ratio with stale complaints means TTLs are too long.

## Why it matters

Getting what-to-cache and TTL right is the core of effective caching. Cache the wrong things and you add complexity for no gain; set TTLs too long and you serve stale data; too short and you lose the benefit. Using staleness tolerance to pick TTLs, adding explicit invalidation for correctness, and watching hit ratio gives you a principled, measurable way to cache.