Cache data li hija għalja biex tiġi prodotta, qrajta ħafna drabi, u tinbidel rarament — dik hija fejn il-caching jagħti riżultat l-aħjar. Il-TTL (time to live) hija compromise bejn freshness (kemm għandu jkun ażżornata d-data) u staleness tolerance (kemm tista' tkun ħamsa għal kemm żmien).
Candidat tajjeb għall-cache jiskorja għoli fuq it-tlieta:
M'għandekx cache data li tkun ċheap biex tiġi compute, write-heavy, jew per-user-secret data li l-freshness tiegħa għandu jkun eżatt (eż. account balances fil-mument ta' transaction).
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
Għal-correctness fuq data li tinbidel b'mod impredittibili, ikkombina TTL ma' explicit invalidation: write-through jew delete-on-write sabiex il-cache tiġi bust fil-mument li l-source tinbidel, minflok li nistenna għall-expiry.
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
Observa l-cache hit ratio biex twaqqaf il-TTLs: ratio baxxa tfisser li qatt ma qed cache; ratio għolja ma' complaints dwar staleness tfisser li l-TTLs huma twal wisq.
Il-għażla korretta ta' x'għandek cache u l-TTL hija l-qalb ta' caching effettiv. Cache the wrong things u żżid komplessità mingħajr benefiċċju; sett TTLs twal wisq u iservi data stale; qasira wisq u titlef il-benefiċċju. L-użu tal-staleness tolerance biex tagħżel TTLs, iżżid explicit invalidation għall-correctness, u l-monitoraġġ tal-hit ratio jagħtik mod prinċipjat u measurable biex cache.