Performance applicative — cache Redis

Dès la mise en production de l'instance Laravel FR, un système de cache Redis était en place pour servir le catalogue produit et les données associées. Lors de la migration des sites internationaux (DE, ES, IT, NL, UK) vers la plateforme unifiée, les limites du cache existant sont devenues bloquantes. La décision a été prise de reconstruire entièrement le système dans un package dédié : pkg-cache.

Le cache existant n'avait pas été conçu pour du multi-site : chaque site disposant de son propre catalogue, il n'existait pas de nomenclature de clés permettant d'identifier et d'isoler les données par site et par langue. Le comportement du cache était instable, avec des invalidations non maîtrisées qui déclenchaient des reconstructions complètes. Ces reconstructions consommaient énormément de ressources et ralentissaient le site de façon significative, faute de mécanisme permettant de reconstruire le cache en arrière-plan sans impacter le front-end.

Une nomenclature de clés structurée a été définie pour couvrir le multi-site et le multi-langue. Chaque clé suit le format {env}:{site}:{entité}:{id} avec un identifiant de langue lorsque nécessaire (exemple : live:fr:product:123, live:be:country:78:2). Le préfixe live désigne le cache actif lu par le front-end.

Deux types de caches ont été introduits : les caches entity (ou main), qui stockent les objets de référence comme les produits, catégories et marques, et les caches satellite, qui dépendent des caches entity et stockent des données dérivées (exemple : live:fr:categories:123:products liste les IDs de produits rattachés à une catégorie). L'invalidation d'un cache main déclenche automatiquement la reconstruction de tous ses satellites.

Le mécanisme warm/cold a été mis en place pour éliminer tout impact sur le front lors d'une reconstruction. Le nouveau cache est construit sous le préfixe next, puis basculé atomiquement en live via des commandes Redis dans Laravel – le front-end ne perçoit aucune interruption.

L'invalidation du cache est pilotable depuis le BO (via une requête API vers le front) ou via des commandes Artisan, au niveau d'un cache entity ou d'un cache satellite précis. Un cron planifié vérifie l'intégrité du cache : il compare le nombre de clés présentes au seuil minimum attendu et déclenche automatiquement une régénération si nécessaire, avec envoi d'une alerte aux développeurs et au CTO. Les commandes peuvent également être exécutées manuellement. Une seule base Redis (DB 0) est utilisée en production, simplifiant la configuration et la maintenance.