Casha data som är dyr att producera, läses ofta och förändras sällan — det är där caching lönar sig mest. TTL (time to live) är en avvägning mellan aktualitet (hur aktuell datan måste vara) och tolerans för föråldrad data (hur fel den kan vara och hur länge).
En bra cache-kandidat får höga poäng i alla tre kategorier:
Casha inte billig-att-beräkna, skrivintensiv eller per-användare-hemlig data vars aktualitet måste vara exakt (t.ex. kontosaldon vid tidpunkten för en transaktion).
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
För korrekthet på data som förändras oförutsägbart, kombinera TTL med explicit invalidering: write-through eller delete-on-write så att cachen töms i det ögonblick källan förändras, istället för att vänta på förfallodatum.
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
Övervaka cache hit-kvoten för att justera TTL-er: ett lågt förhållande betyder att du nästan inte cachar något; ett högt förhållande med klagomål om föråldrad data betyder att TTL-erna är för långa.
Att få rätt på vad som ska cachas och TTL är kärnan i effektiv caching. Casha fel saker och du lägger till komplexitet utan vinning; ställ in TTL-er för långt och du serverar föråldrad data; för kort och du förlorar fördelen. Genom att använda tolerans för föråldring för att välja TTL-er, lägga till explicit invalidering för korrekthet och övervaka hit-kvoten får du ett principiellt, mätbart sätt att casha.