Un ingénieur Python raconte comment il a conçu seul une passerelle API avec FastAPI capable de gérer plus de 200 000 requêtes par jour, en partageant les défis architecturaux rencontrés et les solutions mises en œuvre pour un système hautement performant.

L’objectif initial était de centraliser l’accès à plus de vingt modèles d’IA (OpenAI, Gemini, Sora, etc.), chacun ayant des formats d’authentification, des structures de requêtes/réponses et des comportements asynchrones différents. Plutôt que de multiplier les intégrations directes dans chaque client (comme un bot Telegram), il a opté pour une passerelle API unifiée, évitant ainsi un code spaghetti ingérable.

Le premier défi était la gestion des tâches longues, certaines modèles générant des vidéos en 3 à 5 minutes. Une première approche naïve avec une file d’attente dans MongoDB, où les workers interrogeaient en boucle les tâches en attente, s’est avérée inefficace et coûteuse en ressources. La solution définitive a été d’adopter RabbitMQ : le serveur API (producteur) publie une tâche dans une queue et répond immédiatement au client avec un code 202 Accepted, tandis que des workers dédiés (consommateurs) traitent les messages de manière asynchrone. Pour garantir la fiabilité, deux mécanismes ont été implémentés : les acknowledgements (confirmation après traitement réussi) et une Dead Letter Queue (DLQ) pour isoler les tâches systématiquement en échec, évitant ainsi les blocages.

Côté stockage, une approche hybride a été adoptée : PostgreSQL (ou MySQL) pour les données structurées et transactionnelles (profils utilisateurs, facturation), et MongoDB pour les données opérationnelles et flexibles (états des tâches, résultats en JSON). Cependant, une erreur initiale a failli compromettre le système : le stockage direct d’images encodées en Base64 dans MongoDB a fait gonfler la base à 8 Go pour seulement 180 000 enregistrements. Le correctif a consisté à appliquer un modèle "Pass by Reference" : les fichiers sont d’abord uploadés sur un stockage compatible S3, et seule leur URL est enregistrée dans la base, réduisant ainsi son volume de 90 % et améliorant considérablement les performances.

Pour gérer seul un projet d’une telle envergure, l’auteur compare sa méthode à celle d’un chef d’orchestre : il définit les problèmes (comme la croissance excessive de la base), conçoit les solutions (externalisation vers S3), puis délègue l’implémentation technique à des assistants IA, se concentrant sur l’architecture et la qualité. Parmi les enseignements clés, il souligne l’importance d’utiliser dès le départ des outils industriels comme RabbitMQ, de choisir le bon système de stockage pour chaque type de données, et d’anticiper les goulots d’étranglement plutôt que d’attendre les pannes.

Malgré son jeune âge (18 ans), son expérience illustre que la conception de systèmes high-load repose avant tout sur des choix architecturaux réfléchis, une veille proactive et une approche modulaire, même en solo. Le partage de ce retour d’expérience vise à inspirer d’autres développeurs confrontés à des défis similaires de scalabilité et de fiabilité.