Étude de cas · Mission freelance
Stabiliser une API de données à mesure que ses usages augmentent
Lors d’une mission freelance, j’ai été recruté pour stabiliser une API de données très sollicitée, avec des temps de réponse élevés et des erreurs en période de forte charge.
J’ai proposé, conçu et mis en place le versionnement de l’API. Cette décision a rendu possible l’introduction progressive des sous-ressources sans imposer une rupture aux applications déjà connectées.
La plateforme en un coup d’œil
L’API exposait plusieurs référentiels liés et s’appuyait déjà sur Varnish pour mettre les réponses en cache. Le schéma résume les composants concernés par la mission.
Vue simplifiée de la plateforme concernée par la mission.
La mission
L’API exposait des données variées, issues de plusieurs domaines métier et réparties entre des référentiels liés. De nombreuses réponses dépendaient de relations et de jointures entre ces données. L’API était consommée par de nombreuses applications.
L’enjeu était de stabiliser la plateforme pour qu’elle puisse absorber une montée en charge rapide et durable à mesure que de nouvelles applications se connectaient à l’API.
La situation à mon arrivée
L’API répondait lentement et les applications qui l’utilisaient rencontraient des erreurs, surtout pendant les périodes de forte charge.
Varnish était déjà en place. Le problème principal concernait l’invalidation du cache : une modification dans une locale pouvait vider toutes les réponses mises en cache pour ce référentiel, dans toutes les locales. Comme les référentiels étaient liés, une stratégie fiable devait aussi prendre en compte les réponses dépendantes susceptibles d’être affectées par cette modification.
Le diagnostic
J’ai utilisé EXPLAIN sur PostgreSQL pour analyser les requêtes les plus lentes et comprendre la façon dont la base les exécutait. Cette analyse a fait ressortir plusieurs problèmes dans l’accès aux données et les index utilisés à travers les nombreuses relations du modèle.
J’ai également analysé la façon dont API Platform et Varnish géraient les réponses. Les en-têtes de langue et les traductions avec Gedmo influençaient les résultats, tandis que les liens entre référentiels rendaient difficile l’identification précise des entrées à invalider.
Les évolutions mises en place
Réécriture complète de la bibliothèque de cache et de l’invalidation
J’ai entièrement réécrit la bibliothèque utilisée pour mettre en cache les réponses d’API Platform et mis en place des tags de dépendance associés aux données et aux relations utilisées par chaque réponse. La logique séparait l’identification des dépendances, leur propagation entre référentiels et l’invalidation des tags concernés. La détection en profondeur prenait aussi en compte les dépendances indirectes, afin de n’invalider que les entrées de cache affectées par une modification.
Versionnement de l’API et sous-ressources
J’ai impulsé et mis en place le versionnement de l’API pour faire évoluer le modèle de réponse et introduire des sous-ressources sans casser les applications et les consommateurs existants. Cette approche a donné aux équipes un moyen maîtrisé d’enrichir l’API tout en conservant les intégrations existantes.
Optimisation de la base de données
J’ai amélioré les requêtes PostgreSQL les plus coûteuses et ajouté ou ajusté les index à partir des plans d’exécution observés pendant l’analyse.
Une invalidation guidée par les dépendances
Lorsqu’une donnée changeait, le système suivait les dépendances directes et indirectes entre référentiels pour sélectionner uniquement les tags des réponses concernées.
Une donnée évolue
Une modification intervient dans un référentiel ou une locale.
Les dépendances sont détectées
La logique suit les liens directs et indirects entre référentiels.
Les tags sont ciblés
Les tags associés aux réponses impactées sont sélectionnés.
Le cache reste cohérent
Seules les entrées nécessaires sont invalidées dans Varnish.
Les résultats
L’objectif n’était pas d’atteindre un chiffre précis, mais de stabiliser la plateforme pour qu’elle puisse absorber une montée en charge rapide et durable à mesure que de nouvelles applications se connectaient à l’API. Au fil du temps, le trafic mensuel est passé de 7 à 55 millions d’appels, avec des temps de réponse fortement réduits ; les erreurs observées avant les évolutions ne se reproduisaient plus.
Le versionnement a permis d’ajouter progressivement des sous-ressources tout en maintenant le fonctionnement des applications existantes.
Mon rôle
En tant que Lead PHP / Symfony, j’ai conduit le diagnostic et porté les choix techniques jusqu’à la mise en œuvre des évolutions.
Votre API rencontre un problème similaire ?
Si une API ralentit ou devient difficile à faire évoluer à mesure que son usage augmente, je peux aider à identifier ce qui la limite et construire une trajectoire plus sûre.
Parler d’un projet