Cas pratique : -42 % de latence sur une API GraphQL
Comment une démarche d’observabilité, de modélisation des requêtes et de cache ciblé a transformé les temps de réponse d’une plateforme métier à fort trafic.
Le contexte : une API flexible, mais sous tension
Notre client exploite une plateforme web permettant de rechercher, comparer et personnaliser des offres. Son front-end React consomme une API GraphQL développée en Node.js et TypeScript. Cette architecture avait simplifié l’évolution fonctionnelle : chaque écran pouvait demander exactement les données dont il avait besoin.
Avec la croissance du catalogue et du trafic, cette souplesse a toutefois révélé ses limites. Sur les parcours les plus consultés, le temps de réponse médian dépassait 420 ms et le 95e percentile atteignait régulièrement 1,2 seconde. Les ralentissements étaient particulièrement visibles sur mobile, où plusieurs résolveurs étaient sollicités au chargement initial.
Étape 1 : mesurer avant de modifier
La première décision a été de ne pas optimiser à l’intuition. Nous avons instrumenté la chaîne complète avec des traces distribuées, des métriques Prometheus et des journaux structurés. Chaque requête GraphQL était corrélée à son opération, ses variables, ses résolveurs et ses appels vers les services internes.
Cette cartographie a distingué trois causes souvent confondues : le temps d’attente réseau, le coût d’exécution des résolveurs et la lenteur des accès aux données. Les traces ont montré que la base de données n’était pas seule responsable. Une requête de liste déclenchait parfois plusieurs appels répétitifs pour récupérer les informations associées à chaque élément : un cas classique de problème N+1.
Étape 2 : corriger le problème N+1
Nous avons introduit une stratégie de regroupement avec DataLoader. Au lieu d’exécuter un appel pour chaque identifiant, le serveur rassemble les clés demandées pendant le cycle d’exécution, puis effectue une lecture groupée. Cette approche réduit le nombre d’allers-retours tout en conservant une API GraphQL claire pour les consommateurs.
La correction a été appliquée progressivement, résolveur par résolveur, avec des tests de non-régression et des scénarios de charge. Nous avons également vérifié que le regroupement respectait l’isolation entre utilisateurs : les caches de courte durée restent associés au contexte de la requête et ne peuvent pas mélanger des données privées.
Étape 3 : rendre les requêtes plus prévisibles
GraphQL donne beaucoup de liberté au client, mais cette liberté doit être encadrée côté serveur. Nous avons ajouté des limites de profondeur, un coût maximal par requête et une liste d’opérations connues pour les parcours critiques. Les requêtes persistées permettent par ailleurs de valider à l’avance les opérations utilisées par l’application web.
La sélection des champs a aussi été revue. Certains résolveurs calculaient des informations coûteuses alors qu’elles n’étaient pas demandées dans la réponse finale. Une séparation plus nette entre champs essentiels et champs enrichis a réduit le travail CPU et facilité le dimensionnement des pods Kubernetes.
Étape 4 : mettre en place un cache utile
Le cache n’a pas été appliqué globalement. Nous avons identifié les données stables, comme certaines catégories et règles éditoriales, puis défini des durées de vie adaptées. Les réponses publiques peuvent être réutilisées plus longtemps, tandis que les données personnalisées restent isolées et bénéficient d’un cache plus court.
Un cache distribué a été placé devant les traitements coûteux, avec invalidation déclenchée lors des mises à jour métier. Cette stratégie évite de servir des données obsolètes tout en diminuant la pression sur les services en aval. Des en-têtes cohérents ont également amélioré la réutilisation côté navigateur et réseau interne.
Déploiement progressif et résultats
Les changements ont été livrés en trois sprints. Chaque sprint comprenait une mesure de référence, une modification limitée, puis un test de charge reproduisant les parcours réels. Le déploiement final s’est appuyé sur une stratégie progressive dans Kubernetes : une faible part du trafic a d’abord été dirigée vers la nouvelle version, avant une montée en charge contrôlée.
Après stabilisation, la latence médiane est passée de 420 à 244 ms, soit une réduction de 42 %. Le 95e percentile a diminué de 1,2 seconde à environ 500 ms. Le nombre de requêtes traitées par instance a augmenté de 31 %, sans hausse proportionnelle des ressources consommées.
Les enseignements pour une architecture GraphQL durable
- Instrumenter les résolveurs avant toute optimisation afin de cibler les vrais goulets d’étranglement.
- Traiter le problème N+1 dès la conception des accès aux données.
- Encadrer la complexité des requêtes pour protéger l’infrastructure.
- Adapter le cache à la volatilité et à la sensibilité de chaque donnée.
- Déployer par étapes et comparer les résultats avec des indicateurs reproductibles.
Cette méthode dépasse le seul cas de GraphQL. Elle s’intègre dans une démarche d’architecture haute performance où observabilité, sécurité et évolutivité sont traitées ensemble. Découvrez tous nos services et notre approche technique sur notre page d’accueil.