Pune în cache datele care sunt scumpe de produs, citite frecvent și se schimbă rar — acolo caching-ul plătește cel mai mult. TTL-ul (time to live) este un compromis între freshness (cât de actuală trebuie să fie data) și toleranță la staleness (cât de greșită poate fi și pentru cât timp).
Un bun candidat pentru cache are scor înalt pe toate trei aspecte:
Nu pune în cache date ieftine de calculat, care se scriu mult, sau date secrete per-utilizator a căror freshness trebuie să fie exact (de ex. balanțe de cont la momentul unei tranzacții).
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
Pentru corectitudine pe date care se schimbă imprevizibil, combină un TTL cu invalidare explicită: write-through sau delete-on-write ca cache-ul să fie șters în momentul în care sursa se schimbă, în loc să aștepți expirarea.
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
Urmărește cache hit ratio pentru a acorda TTL-urile: un ratio scăzut înseamnă că abia pui în cache; un ratio înalt cu plângeri de staleness înseamnă că TTL-urile sunt prea lungi.
A alege corect ce să pui în cache și ce TTL să folosești este esența caching-ului efectiv. Dacă pui în cache lucrurile greșite adaugi complexitate fără beneficiu; dacă setezi TTL-urile prea lungi servești date stale; prea scurte și pierzi beneficiul. Folosind toleranța la staleness pentru a alege TTL-uri, adăugând invalidare explicită pentru corectitudine și urmărind hit ratio-ul îți oferă o cale principiată și măsurabilă pentru caching.