Décision : quelle stratégie de cache ?

Un cache conserve les données fréquemment lues dans une couche rapide devant la base (par ex. Redis), réduisant la latence et la charge de la base. Mais toutes les données ne se prêtent pas au cache, et une mauvaise invalidation crée un risque de données obsolètes/incorrectes. Cet arbre vérifie d'abord si vous avez vraiment besoin d'un cache, puis vous aide à choisir entre cache-aside, read-through, write-through et write-behind selon le schéma lecture/écriture, et traite la prévention des stampedes.

À quoi ressemble votre charge : forte lecture ou forte écriture ?

Un cache est le plus rentable lorsque les mêmes données sont lues de nombreuses fois (forte lecture) et changent peu. Établissez d'abord le schéma global : les données sont-elles beaucoup lues et rarement modifiées, sont-elles mises à jour en permanence, ou ne savez-vous pas si ajouter un cache en vaut la peine ?

• Très forte lecture, données relativement peu modifiées
• Écritures également fortes ; les données écrites sont lues immédiatement/souvent
• Pas sûr ; ai-je vraiment besoin d'un cache ?

Qui doit être responsable du remplissage du cache ?

Dans un scénario à forte lecture, le choix clé est de savoir qui remplit le cache. Votre application doit-elle gérer le cache explicitement et se replier elle-même sur la base (grande flexibilité), ou la couche de cache doit-elle récupérer les données dans la base sous-jacente en cas d'absence et les renvoyer de façon transparente ?

• L'application le gère explicitement ; je veux flexibilité et contrôle
• La couche de cache récupère depuis la base en cas d'absence (transparent)

En écriture, la priorité est-elle la cohérence ou la vitesse d'écriture ?

Si les écritures sont fortes, vous devez décider du degré de cohérence des données écrites entre le cache et la base. Le cache et la base doivent-ils être mis à jour ensemble à chaque écriture pour garantir la cohérence (écritures un peu plus lentes), ou les écritures doivent-elles aller d'abord dans le cache et être appliquées à la base de façon asynchrone en arrière-plan (écritures très rapides mais risque de perte) ?

• La cohérence compte ; les lectures doivent toujours être à jour
• La vitesse d'écriture est critique ; une cohérence légèrement différée et un risque de perte sont acceptables

Recommandation : n'ajoutez pas de cache pour l'instant

Un cache n'est pas gratuit : il introduit un problème de cohérence (données obsolètes), une infrastructure supplémentaire et la complexité de l'invalidation. Si la requête est déjà rapide ou si les données changent à chaque requête, un cache n'apporte aucun bénéfice, seulement une surface de panne.

Recommandation : cache-aside (lazy loading)

Avec le cache-aside, l'application consulte d'abord le cache ; si la donnée est absente (miss), elle la lit dans la base, l'écrit dans le cache et la renvoie. C'est le schéma le plus courant et le plus flexible ; le cache ne se remplit qu'avec les données réellement demandées.

Recommandation : cache read-through

Avec le read-through, l'application ne communique qu'avec le cache ; en cas d'absence, la couche de cache récupère elle-même les données dans la base et se remplit (via un provider/loader). Le code applicatif devient plus simple et la logique de remplissage est centralisée.

Recommandation : cache write-through

Avec le write-through, chaque écriture va à la fois dans le cache et dans la base (de façon synchrone) ; les deux sont mis à jour ensemble. Le cache n'est donc jamais en retard sur la base et les lectures voient toujours des données à jour.

Recommandation : cache write-behind (write-back)

Avec le write-behind, l'écriture va d'abord dans le cache et rend immédiatement la main à l'utilisateur ; l'écriture dans la base a lieu en arrière-plan, de façon asynchrone (par lots/différée). La vitesse d'écriture est maximale, mais elle comporte des risques de durabilité et de cohérence.