Cache data, der er dyr at producere, læses hyppigt og ændrer sig sjældent — det er her caching betaler sig mest. TTL (time to live) er et kompromis mellem freshness (hvor aktuelle data skal være) og staleness tolerance (hvor forkert de kan være og hvor længe).
En god cache-kandidat scorer højt på alle tre punkter:
Ikke cache billige-at-compute, write-heavy eller per-user-secret data hvis freshness skal være nøjagtig (f.eks. kontosaldi på tidspunktet for 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
For korrekthed på data, der ændres uforudsigeligt, kombinér TTL med eksplicit invalidering: write-through eller delete-on-write, så cachen tømmes på det moment kilden ændres, i stedet for at vente på udløb.
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åg cache hit ratio for at tuning TTLs: et lavt forhold betyder, at du næsten ikke cacher; et højt forhold med forældet-klager betyder, at TTLs er for lange.
At få det rigtige hvad-at-cache og TTL er kernen i effektiv caching. Cache de forkerte ting og du tilføjer kompleksitet uden gevinst; sæt TTLs for lange og du serverer forældet data; for korte og du mister fordelen. At bruge staleness tolerance til at vælge TTLs, tilføje eksplicit invalidering for korrekthed og overvåge hit ratio giver dig en principiel, målbar måde at cache på.