Cachirirajte podatke koji su skupi za proizvodnju, često se čitaju i rijetko se mijenjaju — tu je cachiranje najisplativije. TTL (time to live) je kompromis između svježine (koliko su podaci trebali biti trenutni) i tolerancije zastarjelosti (koliko mogu biti pogrešni i kako dugo).
Dobar kandidat za cache dobija visok rezultat na sva tri kriterija:
Ne cachirirajte podatke koji su jeftini za računanje, s puno pisanja, ili tajne podatke po korisniku čija svježina mora biti točna (npr. stanja računa u trenutku transakcije).
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
Za ispravnost podataka koji se nepredvidivo mijenjaju, kombinirajte TTL s eksplicitnom invalidacijom: write-through ili delete-on-write kako bi se cache odmah očistio kada se izvor promijeni, umjesto čekanja na isteka.
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
Praćenjem cache hit ratio prilagodite TTL: nizak omjer znači da gotovo ne cachirati; visok omjer sa žalbama o zastarjelosti znači da su TTL predugi.
Ispravno odabiranje što cachirati i TTL je srž učinkovitog cachiranja. Cachiranje pogrešnih stvari dodaje složenost bez dobiti; postavljanje TTL predugo služi zastarjele podatke; premalo i gubite dobit. Korištenjem tolerancije zastarjelosti za odabir TTL, dodavanjem eksplicitne invalidacije za ispravnost i praćenjem hit ratio dobijate principijelan, mjerljiv način cachiranja.