Un cache doit définir ce qui peut être temporaire, quand une valeur expire et comment une modification invalide la copie conservée.
Le cache réduit une lecture répétée, mais il peut servir une ancienne autorisation ou un ancien total. Commencez par classer les données. Une liste de pays tolère une durée longue. Un statut de commande ou un droit de lecture demande une invalidation plus stricte.
Choisir la clé
La clé doit contenir les paramètres qui influencent la réponse : identifiant d’entreprise, utilisateur lorsque les droits varient, langue, filtre et version. Une clé trop courte peut partager une réponse entre deux espaces. Une clé trop longue réduit les réutilisations.
Définir l’expiration
Une durée maximale limite l’âge d’une copie, mais elle ne remplace pas l’invalidation après une écriture. Le logiciel doit préciser s’il affiche une valeur éventuellement ancienne ou s’il relit la source. L’interface peut indiquer qu’une mise à jour est en cours pour un traitement différé.
Invalider après changement
Une modification doit retirer les clés concernées ou les marquer obsolètes. Les listes, compteurs et détails liés peuvent utiliser des caches distincts. Une règle centralisée réduit les oublis quand plusieurs services écrivent la même donnée.
Les données d’autorisation et les frontières entre entreprises exigent une attention particulière. Testez un changement de rôle et une modification d’espace avec le cache actif. Les règles d’isolation SaaS doivent rester vraies même lorsque la réponse vient du cache.
Mesurer l’effet
Suivez les lectures en cache, les expirations, les invalidations et les erreurs de cohérence. Un cache qui accélère une page mais augmente les corrections manuelles n’apporte pas le résultat attendu.
Sources : Microsoft, cache-aside, OWASP, contrôle d’accès.
Choisir les données cachables
Une donnée de référence rarement modifiée peut avoir une durée longue. Une liste de statuts ou de pays peut être relue depuis le cache sans gêner une décision immédiate. Un solde, un droit ou un état de paiement demande une règle plus stricte, car une valeur ancienne peut déclencher une action incorrecte.
Documentez la fraîcheur acceptable pour chaque type. Une donnée peut être relue depuis la source après une écriture, tandis qu’une liste secondaire peut attendre quelques secondes. L’équipe doit connaître ce compromis au moment de la conception et de la recette.
Éviter le partage involontaire
Une clé de cache doit contenir l’identifiant d’entreprise lorsque les espaces sont séparés. Si la réponse dépend du rôle, de la langue ou de la période, ces éléments appartiennent aussi à la clé. Un identifiant d’objet seul peut retourner une réponse préparée pour un autre utilisateur.
Testez deux entreprises avec les mêmes identifiants et des contenus différents. Essayez une modification de rôle, une déconnexion et un changement de langue. Les permissions par rôle restent applicables même lorsque le serveur répond depuis le cache.
Gérer les échecs
Le cache peut être indisponible, plein ou lent. Décidez si l’application relit la source, sert une valeur connue ou arrête l’opération. Une validation financière doit généralement privilégier une donnée confirmée. Un écran informatif peut afficher une valeur ancienne avec une date visible.
Les reprises doivent éviter de remplir le cache avec une réponse vide produite par une panne. Ajoutez un délai et une limite lorsque plusieurs requêtes cherchent la même donnée après expiration. Surveillez le nombre de relances et la durée ajoutée.
Nettoyer les entrées
Une migration de schéma ou un changement de définition peut rendre des entrées anciennes incorrectes. Invalidez la version précédente ou ajoutez une version à la clé. Après une suppression logique, retirez les détails et les listes associés selon la règle de cycle de vie.
Mesurez les taux de lecture, d’écriture, d’expiration et d’invalidation. Un cache qui a peu de réutilisations ajoute une complexité sans gain clair. Revoir périodiquement les clés et les durées évite de conserver des règles qui ne correspondent plus au produit.