Memorizoni në cache të dhëna që janë të shtrenjta për të prodhuar, lexohen shpesh dhe ndryshojnë rrallë — atje ku caching-u ka përfitime maksimale. TTL (time to live) është një kompromis midis freskisë (sa aktuale duhet të jenë të dhënat) dhe tolerancës ndaj vjetërsisë (sa të gabuara mund të jenë dhe për sa kohë).
Një kandidat i mirë për cache ka rezultat të lartë në të tre kategoritë:
Mos memorizoni në cache të dhëna të lira për të llogaritur, të hapura ndaj shkrimeve, ose të fshehura për përdoruesit ku freskia duhet të jetë e saktë (p.sh. bilancet e llogarisjeve në momentin e një transaktsioni).
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
Për saktësi të të dhënave që ndryshojnë në mënyrë të paparashikueshme, kombinoni TTL-in me përjashtime eksplicite: write-through ose delete-on-write në mënyrë që cache-u të bëhet i pavlefshëm menjëherë kur burimi ndryshon, në vend të pritjes për skadencën.
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
Monitoroni cache hit ratio-n për të kalibruar TTL-et: një raport i ulët do të thotë se nuk po memorizoni pothuajse asgjë; një raport i lartë me ankesa për vjetërsi do të thotë se TTL-et janë shumë të gjata.
Marrja e vendimit se çfarë të memorizohet në cache dhe TTL-i janë bërthama e cache-imit efektiv. Memorizoni në cache gjërat e gabuar dhe shtoni kompleksitet pa asnjë përfitim; vendosni TTL-et shumë të gjata dhe shërbeni të dhëna të vjetra; shumë të shkurta dhe humbni përfitimin. Përdorimi i tolerancës ndaj vjetërsisë për të zgjedhur TTL-et, shtimi i përjashtime eksplicite për saktësi, dhe monitorimi i hit ratio-n ju jep një mënyrë të qetë, të matshme për caching.