Cachuj dane, które są drogie do wygenerowania, czytane często i zmieniane rzadko — tam caching przynosi największe korzyści. TTL (time to live) to kompromis między świeżością (jak aktualne dane muszą być) a tolerancją na nieaktualność (jak błędne mogą być i na jak długo).
Dobry kandydat do cache'u wynika wysoko na trzech kryteriach:
Nie cachuj tanich do obliczenia, write-heavy, lub danych tajnych dla użytkownika, których świeżość musi być dokładna (np. saldo konta w momencie transakcji).
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
Dla poprawności danych, które zmieniają się nieprzewidywalnie, połącz TTL z jawną inwalidacją: write-through lub delete-on-write, żeby cache został wyczyszczony w momencie, gdy źródło się zmieni, zamiast czekać na wygaśnięcie.
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
Obserwuj współczynnik trafień cache'u (cache hit ratio), aby dostroić TTL: niski wskaźnik oznacza, że praktycznie nic nie cachujesz; wysoki wskaźnik ze skargami na nieaktualność oznacza, że TTL są zbyt długie.
Prawidłowe dobranie co-do-cache'u i TTL to sedno efektywnego cachingu. Cachuj złe rzeczy i dodajesz złożoność bez korzyści; ustaw TTL za długo i serwujesz nieaktualne dane; za krótko i tracisz benefity. Używanie tolerancji na nieaktualność do wyboru TTL, dodawanie jawnej inwalidacji dla poprawności i obserwowanie współczynnika trafień daje ci systematyczny, mierzalny sposób na cachowanie.