Stratégie cache data
Statut
Document de cadrage data — version initiale.
Objectif
Le cache data doit réduire la charge sur PostgreSQL et accélérer les usages fréquents, sans servir de données obsolètes dans les contextes sensibles.
État actuel visible
Les migrations Laravel incluent une table cache.
La configuration applicative complète du cache n'est pas documentée dans les fichiers ciblés et doit être confirmée par environnement.
Données candidates au cache
| Donnée | Intérêt |
|---|---|
| Communes | Lecture fréquente, faible variation. |
| Tags et catégories | Référentiels partagés. |
| Feature tabs | Configuration lue souvent. |
| Plans et catalogues | Données commerciales peu fréquentes. |
| Acteurs publics validés | Listes par commune, sous réserve d'invalidation. |
| Services communaux | Lecture publique fréquente. |
| Agrégats analytics | Calculs coûteux. |
Données à éviter
- droits utilisateur non invalidables ;
- données de paiement ;
- données privées ;
- modération en cours ;
- alertes urgentes sans TTL court ;
- contexte IA sensible ;
- tokens ou secrets.
Principes
- Définir un TTL par type de donnée.
- Invalider sur modification métier.
- Préférer des clés incluant commune, acteur et version si utile.
- Éviter le cache pour masquer des requêtes mal conçues.
- Mesurer le taux de cache.
Cache et API
Le cache doit être piloté par l'API Laravel cible, pas par une logique dispersée dans les frontends.
Les frontends peuvent utiliser du cache client, mais les règles de fraîcheur métier doivent rester maîtrisées côté backend.
Points à clarifier
- Driver cache par environnement.
- TTL officiels.
- Invalidation par module.
- Cache CDN vs cache application.
- Cache des réponses de recherche.