Cache data som er dyr å produsere, leses ofte, og endres sjelden — det er der caching lønner seg mest. TTL (time to live) er en avveining mellom friskhet (hvor aktuell dataene må være) og toleranse for foreldet data (hvor feil det kan være og hvor lenge).
En god cache-kandidat scorer høyt på alle tre:
Ikke cache billig-å-beregne, skriv-tung, eller per-bruker-hemmelig data hvis friskhet må være eksakt (f.eks. kontosaldoer på tidspunktet for en transaksjon).
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 korrekthet på data som endres uforutsigbart, kombinere TTL med eksplisitt invalidering: write-through eller delete-on-write slik at cachen tømmes i det øyeblikket kilden endres, i stedet for å vente på utløp.
on update(record):
db.save(record)
cache.delete(key(record)) // invalidate now, don't serve stale until TTL
hit ratio = hits / (hits + misses)
high (>90%) → cache is doing its job
low → TTL too short, keys too granular, or data not cacheable
Overvåk cache hit ratio for å justere TTLer: et lavt forhold betyr at du knapt cacher; et høyt forhold med foreldethetsklagsmål betyr at TTLer er for lange.
Å få hva-som-skal-caches og TTL riktig er kjernen i effektiv caching. Cache de feil tingene og du legger til kompleksitet uten gevinst; sett TTLer for lange og du serverer foreldet data; for korte og du mister fordelen. Å bruke toleranse for foreldethet til å velge TTLer, legge til eksplisitt invalidering for korrekthet, og overvåke hit ratio gir deg en prinsippiell, målbar måte å cache på.