Qu’est-ce qu’un cache distribué et comment gérer ses pannes ?

Question

IT Interview Practice · Accepted Answer

**Un cache distribué permet à plusieurs instances applicatives de réutiliser des données via le réseau.** Il évite de répéter un travail coûteux, à condition de définir clairement la fraîcheur attendue et le comportement en cas de panne.

Imaginez trois instances backend lisant le même catalogue. Avec un cache dans chaque processus, chacune entretient sa propre copie. Avec un service de cache partagé, une instance peut charger une valeur que les autres réutilisent. Ce service peut lui-même comporter plusieurs nœuds.

## 1. Décider ce qui peut être mis en cache sans risque

Commencez par le coût de production des données et l’ancienneté acceptable. Une description de produit peut tolérer un léger retard ; la vérification finale du stock lors d’un achat peut exiger la donnée de référence.

Définissez une clé identifiant le résultat complet, avec le client locataire, la langue et les autres paramètres pertinents. Sinon, un cache rapide peut renvoyer les données du mauvais client. La base doit rester la référence pour les données métier durables, car les valeurs en cache peuvent disparaître.

## 2. Comprendre les lectures avant de concevoir les mises à jour

Une approche courante est le cache-aside : l’application consulte le cache, lit la base si la valeur manque, puis stocke le résultat avec une durée de validité appelée TTL.

```text
Request -> Cache -> hit  -> Return value
                 -> miss -> Database -> Fill cache -> Return value
```

Cela réduit les lectures répétées en base lorsque beaucoup de requêtes demandent la même valeur. Mais cela ajoute des appels réseau et une dépendance : le cache n’est utile que si le travail évité dépasse ces coûts. Voir le [cache-aside avec Redis](https://redis.io/docs/latest/develop/use-cases/cache-aside/).

## 3. Définir comment les modifications deviennent visibles

Pour le catalogue, un point de départ pratique consiste à valider la modification en base, puis à invalider le produit en cache. La lecture suivante le recharge. Il reste toutefois une course possible : un lecteur récupère l’ancienne valeur avant la validation, puis la remet en cache après l’invalidation.

Le TTL limite la durée de vie de cette copie nouvellement stockée ; il ne garantit pas que chaque lecture voie immédiatement la dernière écriture. Si des droits, prix ou soldes périmés enfreignent les règles de l’opération, vérifiez la donnée de référence ou concevez une mise à jour tenant compte des versions avec des garanties explicites. Le besoin métier détermine la cohérence : utiliser Redis ne la résout pas automatiquement.

## 4. Éviter qu’une absence en cache provoque une panne

Lorsqu’une entrée populaire expire, beaucoup de requêtes peuvent lire simultanément la base. C’est un afflux de rechargements, ou cache stampede. Une panne du cache peut provoquer le même phénomène sur de nombreuses entrées.

- Regroupez les chargements simultanés d’une même clé pour limiter les recalculs ; précisez si la coordination couvre un processus ou toutes les instances.
- Variez les expirations pour éviter qu’un grand nombre d’entrées expirent ensemble. Cela étale les rechargements sans résoudre tous les problèmes de clés très sollicitées.
- Pendant un rechargement, ne servez une ancienne valeur que si le métier autorise des données périmées.
- Utilisez des délais d’attente courts pour le cache et limitez le trafic de repli vers la base. Refuser une partie du travail peut être préférable à une saturation faisant échouer toutes les requêtes.

Testez volontairement ces situations. Un taux élevé de réponses servies par le cache en fonctionnement normal renseigne peu sur le comportement lorsque ce cache disparaît.

## 5. Dimensionner selon la véritable limite

Le sharding répartit les clés entre nœuds ; la réplication conserve des copies pour la disponibilité ou les lectures. Ce sont deux problèmes distincts. Redis Cluster place les clés dans des emplacements de hachage : ajouter des nœuds ne répartit donc pas automatiquement le travail d’une seule clé très sollicitée. Voir la [spécification Redis Cluster](https://redis.io/docs/latest/operate/oss_and_stack/reference/cluster-spec/).

Surveillez le taux de succès du cache, la latence, les délais dépassés, la mémoire, les évictions et la charge arrivant en base. Une éviction retire une valeur pour gérer la mémoire et peut survenir avant son TTL. Une entrée de cache n’est pas un stockage durable garanti pour des données métier ou des tâches en attente.

Pour le catalogue, je commencerais par un cache-aside avec des clés explicites, une politique de fraîcheur et un repli protégé. J’ajouterais des nœuds seulement si les mesures révèlent un problème de capacité que la répartition peut réellement résoudre. **Une bonne conception explique ce qui se passe lorsque la valeur est présente, absente ou incorrecte.**

1. Décider ce qui peut être mis en cache sans risque

2. Comprendre les lectures avant de concevoir les mises à jour

3. Définir comment les modifications deviennent visibles

4. Éviter qu’une absence en cache provoque une panne

5. Dimensionner selon la véritable limite

Questions connexes