Cache gegevens die duur zijn om te produceren, vaak worden gelezen en zelden veranderen — dat is waar caching het meest loont. De TTL (time to live) is een afweging tussen versheid (hoe actueel de gegevens moeten zijn) en staleness tolerantie (hoe onjuist het mag zijn en hoe lang).
Een goede cache-kandidaat scoort hoog op alle drie:
Cache geen goedkope-om-te-berekenen, write-heavy of per-user-geheime gegevens waarvan de versheid exact moet zijn (bijv. rekeningsaldi op het moment van een transactie).
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
Voor correctheid op gegevens die onvoorspelbaar veranderen, combineer je een TTL met expliciete invalidatie: write-through of delete-on-write zodat de cache onmiddellijk wordt gewist wanneer de bron verandert, in plaats van te wachten op vervallen.
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
Let op de cache hit ratio om TTLs af te stellen: een lage ratio betekent dat je nauwelijks cacht; een hoge ratio met klachten over verouderde gegevens betekent dat TTLs te lang zijn.
Het goed kiezen wat je wilt cachen en het instellen van de TTL vormt de kern van effectief cachen. Cache de verkeerde dingen en je voegt complexiteit toe zonder voordeel; stel TTLs te lang in en je serveert verouderde gegevens; te kort en je verliest het voordeel. Door staleness tolerantie te gebruiken voor het kiezen van TTLs, expliciete invalidatie voor correctheid toe te voegen en de hit ratio te volgen, heb je een principieel, meetbaar manier om te cachen.