Un site vidéo à fort trafic a réduit le nombre de requêtes de base de données pour son flux de la page tendance de 4 000 par minute à moins de 50, et a fait chuter son temps de réponse au 95e percentile de 380 ms à 40 ms en passant d'une mise en cache de page entière à une mise en cache par fragments avec Varnish et Edge Side Includes (ESI).

Pourquoi le site avait besoin d'une stratégie de cache différente

La page d'accueil qui affiche les clips les plus regardés de la journée semble identique pour presque tous les visiteurs d'une région : environ 95 % du HTML est identique pour un million d'utilisateurs, tandis que les 5 % restants contiennent des données personnelles telles que le nom de l'utilisateur connecté ou une barre de recherche. L'équipe d'ingénierie était confrontée à deux options peu attrayantes :

  • Mettre en cache la page entière et risquer de servir des données personnelles obsolètes aux utilisateurs connectés.
  • Contourner complètement le cache et laisser chaque requête solliciter la base de données.

Ces deux approches nuisaient à l'expérience utilisateur. L'équipe s'est tournée vers l'ESI, une technique qui permet à un reverse proxy d'assembler une page à partir de fragments mis en cache indépendamment à la périphérie du réseau (edge).

Comment la mise en cache par fragments a été mise en place

Varnish, l'accélérateur HTTP open source, traitait la page comme un squelette composé de trois éléments remplaçables :

  • Grille vidéo – la liste coûteuse des vidéos tendance à l'échelle régionale. Mise en cache pendant 60 secondes car elle change fréquemment mais est identique pour chaque visiteur anonyme.
  • Sélecteur de langue – un élément d'interface statique qui change rarement. Mis en cache pendant 24 heures.
  • En-tête (Header) – le seul fragment véritablement personnel (nom d'utilisateur, avatar, notifications). Jamais mis en cache ; Varnish transmet la requête au serveur d'application à chaque fois.

Lorsqu'une requête arrive, Varnish sert le squelette mis en cache, récupère les deux fragments mis en cache dans son stockage local et insère l'en-tête en direct provenant du backend.

Les chiffres qui comptent

Après le passage à cette stratégie :

  • La charge de la base de données pour la page tendance est passée de 4 000 requêtes par minute à moins de 50.
  • La latence au 95e percentile est tombée de 380 ms à 40 ms.

Trois leçons pratiques tirées du déploiement

1. Les périodes de grâce (grace periods) lissent les échecs de cache Lorsque le TTL d'un fragment expire, Varnish s'interrompt normalement pour récupérer le contenu frais, créant un pic de latence qui peut dégénérer en un « thundering herd » (effet de troupeau) d'appels simultanés vers le backend. En configurant une période de grâce, Varnish continue de servir le fragment obsolète pendant qu'il rafraîchit silencieusement le cache en arrière-plan. Les utilisateurs ne constatent aucune pause ; le backend voit un taux de requête stable et gérable.

2. Supprimer les cookies pour les fragments anonymes Les cookies attachés à chaque requête obligent Varnish à traiter chaque requête comme unique, annulant ainsi les succès de mise en cache (cache hits). L'équipe a supprimé les cookies pour la grille vidéo et le sélecteur de langue, permettant à ces fragments d'être mis en cache de manière agressive. Seul le fragment d'en-tête transporte des cookies, préservant la personnalisation sans sacrifier l'efficacité du cache.

3. Les clés de substitution (surrogate keys) permettent une purge instantanée Parfois, une vidéo doit être supprimée immédiatement — par exemple, pour des raisons de droits d'auteur. Attendre l'expiration du TTL de 60 secondes est inacceptable. En étiquetant chaque fragment mis en cache avec une clé de substitution (surrogate key) qui reflète les identifiants des vidéos sous-jacentes, l'équipe peut émettre une commande de purge unique qui invalide instantanément toutes les copies d'une vidéo spécifique sur chaque nœud de périphérie (edge node). Cela évite un balayage complet du cache et permet au site de rester conforme.

À retenir : La mise en cache par fragments avec Varnish et ESI transforme une page monolithique dépendante de la base de données en un ensemble de pièces légères et réutilisables, réduisant considérablement la charge du backend et la latence tout en préservant la personnalisation par utilisateur.