Metti in cache i dati che sono costosi da produrre, letti frequentemente e cambiano raramente — è dove il caching conviene di più. Il TTL (time to live) è un compromesso tra freschezza (quanto attuali devono essere i dati) e tolleranza della staleness (quanto sbagliati possono essere per quanto tempo).
Un buon candidato per il cache ha un punteggio alto su tutti e tre i criteri:
Non mettere in cache dati economici da calcolare, con molte scritture, o dati per-utente-segreti la cui freschezza deve essere esatta (es. saldi dei conti al momento di una transazione).
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
Per la correttezza su dati che cambiano in modo imprevedibile, combina un TTL con invalidazione esplicita: write-through o delete-on-write così il cache viene azzerato nel momento in cui la fonte cambia, invece di aspettare la scadenza.
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
Monitora il cache hit ratio per accordare i TTL: un rapporto basso significa che stai quasi non cachendo; un rapporto alto con lamentele di staleness significa che i TTL sono troppo lunghi.
Ottenere il cosa-mettere-in-cache e il TTL giusti è il nocciolo del caching efficace. Cachare le cose sbagliate e aggiungi complessità senza guadagno; impostare TTL troppo lunghi e servi dati stantii; troppo corti e perdi il beneficio. Usare la tolleranza della staleness per scegliere i TTL, aggiungere invalidazione esplicita per la correttezza, e monitorare l'hit ratio ti dà un modo principiato e misurabile per cachare.