Concevoir une stratégie de cache applicatif
Concevez une stratégie de cache Redis complète avec patterns appropriés, politique TTL, invalidation et protection contre les stampedes.
Coller dans votre IA
Collez ce prompt dans ChatGPT, Claude ou Gemini et personnalisez les variables entre crochets.
Tu es un architecte systèmes expert en stratégies de mise en cache et en optimisation des performances applicatives. Je dois mettre en place une stratégie de cache robuste pour mon application.
Contexte de l'application :
- Type : [EX: API REST à fort trafic, application web B2C, plateforme de données]
- Stack : [EX: Node.js + PostgreSQL, Python + MongoDB]
- Solution de cache envisagée : [EX: Redis 7, Memcached, cache en mémoire]
- Trafic actuel : [EX: 1000 requêtes/minute, pics à 5000]
- Problème de performance : [EX: requêtes DB trop lentes, API tierce rate-limited, calculs coûteux]
Données candidates au cache :
[LISTER_LES_TYPES_DE_DONNÉES: ex. profils utilisateurs, résultats de recherche, configurations, sessions, tokens JWT révoqués]
Conçois une stratégie de cache complète :
- Analyse des données : classe chaque type de donnée par fréquence d'accès, taux de modification et coût de recalcul pour prioriser ce qui mérite d'être caché.
- Patterns de cache : recommande et implémente les patterns appropriés (Cache-Aside, Write-Through, Write-Behind, Read-Through) pour chaque cas d'usage.
- Politique d'expiration (TTL) : définis des TTL appropriés pour chaque type de donnée avec justification.
- Stratégie d'invalidation : comment invalider le cache lors des mises à jour des données (invalidation par clé, pattern, event-driven).
- Gestion des ratés de cache (Cache Miss) : protection contre le Cache Stampede (thundering herd) et le Cache Penetration.
- Cache distribué : considérations pour un environnement multi-instances (Redis Cluster, serialisation).
- Métriques : métriques à surveiller (hit rate, miss rate, memory usage, évictions) et seuils d'alerte.
Personnaliser ce prompt avec Léa
Léa réécrit ce prompt pour ton métier et ton objectif précis — 3 questions suffisent.
Pourquoi ce prompt fonctionne
<p>Ce prompt est structuré pour aborder le caching comme un problème d'ingénierie systèmes complet. L'analyse initiale par fréquence d'accès et coût de recalcul est l'étape la plus importante : cacher les mauvaises données (données qui changent constamment ou rarement accédées) est pire que de ne rien cacher car cela ajoute de la complexité sans bénéfice.</p><p>La protection contre le Cache Stampede (thundering herd) est souvent ignorée jusqu'au premier incident en production : quand un cache expire, toutes les requêtes simultanées frappent la base de données en même temps, causant exactement la surcharge qu'on essayait d'éviter. Ce prompt force à anticiper ce scénario.</p><p>La demande de métriques spécifiques avec seuils d'alerte transforme la conception en système observable : un hit rate en dessous de 80% indique généralement une mauvaise politique de TTL ou une invalidation trop agressive, des métriques qui permettent de tuner le cache continuellement en production.</p>
Cas d'usage
Résultat attendu
Une stratégie de cache complète avec analyse des données, patterns recommandés, politique TTL, stratégie d'invalidation et métriques de monitoring.
Améliorez ce prompt
Passez ce prompt dans l'Optimiseur pour renforcer le contexte, les contraintes et le format attendu.
Améliore ce prompt avec l'OptimiseurCommentaires
- LéaIA
Ajoute une section "Analyse des coûts de cache vs recalcul" pour justifier le TTL de chaque donnée en fonction de son volume et de son taux d'obsolescence acceptable. Cela évite de cacher des données rarement lues qui consomment inutilement de la mémoire.
Termes du glossaire
📬 Recevez de nouveaux prompts chaque semaine
Rejoignez notre newsletter et ne manquez aucun prompt.
Pour aller plus loin
Prompts similaires
Mise en œuvre de la CSP avec des nonces
Prévenir les XSS avec une CSP stricte
Déboguer une erreur en production
Analysez rapidement une erreur de production avec une approche structurée de Root Cause Analysis et un plan d'action immédiat.
Implémenter l'authentification JWT
Ajouter l'authentification JWT à une API
Prompt GitHub Copilot pour générer du code JavaScript
GitHub Copilot, l'assistant de programmation basé sur l'intelligence artificielle développé par GitHub et OpenAI, a transformé la manière dont les développeurs écrivent du code JavaScript. En s'appuyant sur des milliards de lignes de code open source, Copilot est capable de générer des fonctions complètes, des classes, des modules et même des architectures entières à partir de simples descriptions en langage naturel. Pour tirer le meilleur parti de cet outil, il est essentiel de maîtriser l'art du prompt engineering appliqué à la génération de code. Un prompt bien structuré permet d'obtenir du code JavaScript propre, performant et conforme aux bonnes pratiques modernes (ES2024+, typage implicite, gestion d'erreurs, modularité). Dans ce guide, nous vous proposons des prompts optimisés pour GitHub Copilot qui vous permettront de générer du code JavaScript de qualité professionnelle, que vous développiez une API REST, un composant frontend, un script utilitaire ou une logique métier complexe. Chaque prompt a été conçu pour fournir suffisamment de contexte à Copilot tout en laissant la flexibilité nécessaire à une génération pertinente et adaptée à votre projet.