Mettez en cache les données coûteuses à produire, lues fréquemment et qui changent rarement — c'est là que la mise en cache est la plus rentable. Le TTL (time to live) est un compromis entre la fraîcheur (le caractère actuel des données) et (à quel point les données peuvent être incorrectes et pendant combien de temps).
Un bon candidat pour le cache doit scorer haut sur les trois critères :
Ne mettez pas en cache des données bon marché à calculer, avec beaucoup d'écritures, ou des données secrètes par utilisateur dont la fraîcheur doit être exacte (par exemple, les soldes de compte au moment d'une 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
Pour la justesse sur les données qui changent de manière imprévisible, combinez un TTL avec l'invalidation explicite : write-through ou delete-on-write pour que le cache soit vidé au moment où la source change, au lieu d'attendre l'expiration.
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
Observez le cache hit ratio pour ajuster les TTLs : un ratio faible signifie que vous cachez à peine ; un ratio élevé avec des plaintes sur l'obsolescence signifie que les TTLs sont trop longs.
Bien choisir ce qu'il faut mettre en cache et les TTLs est le cœur d'une mise en cache efficace. Mettre en cache les mauvaises choses ajoute de la complexité sans bénéfice ; fixer des TTLs trop longs vous fait servir des données obsolètes ; trop courts et vous perdez l'avantage. Utiliser la tolérance à l'obsolescence pour choisir les TTLs, ajouter l'invalidation explicite pour la justesse, et observer le hit ratio vous donne une façon de mettre en cache principielle et mesurable.