Un unique backend ne suffisait plus pour une entreprise de santé et de nutrition en pleine croissance. Le trafic du chatbot AI, l'ingestion massive de données de wearables et les requêtes API quotidiennes se disputaient toutes les mêmes ressources — rendant le système difficile à scaler et risqué à déployer. Nous l'avons ré-architecturé en services ciblés, déployables indépendamment, orchestrés derrière une seule API gateway, fonctionnant sur AWS.
Le DĂ©fi
- Une seule base de code gérant toutes les tâches. Un seul workflow incluait la gestion des utilisateurs, l'inférence du chatbot AI, les recettes et l'analyse des données de santé. Un pic dans n'importe quel domaine dégradait l'ensemble de la plateforme, et chaque changement signifiait le redéploiement de l'intégralité du système.
- Profils de ressources extrêmement disparates. Les requêtes de chatbot alimentées par des LLM sont gourmandes en CPU et mémoire, et sont par intermittence ; l'ingestion de données de wearables est intensive en écriture et continue ; les API CRUD principales sont légères et constantes. Dimensionner un seul serveur pour les trois signifiait payer trop cher pour certaines charges de travail et en sous-alimenter d'autres.
- Scalabilité et déploiement indépendants. L'équipe devait scaler la charge de travail AI sans affecter l'API principale, et déployer des changements dans un domaine sans risquer les autres.
Un point d'entrée unique et sécurisé. Malgré de multiples services backend, les clients (mobile, web, admin) avaient besoin d'une interface cohérente et authentifiée pour communiquer — sans exposer la topologie interne des services au monde extérieur.
Notre Solution
Nous avons divisé la plateforme en trois services NestJS ciblés derrière un AWS Application Load Balancer, le serveur principal agissant comme API gateway et orchestrateur. Il gère l'authentification et les domaines principaux, et délègue le travail spécialisé aux microservices de chatbot et de santé via REST authentifié. Une couche de données et de messagerie partagée maintient les services faiblement couplés mais cohérents.
Architecture
- Serveur Principal (NestJS) — API gateway et orchestrateur : authentification, utilisateurs, objectifs, recettes, planification et notifications. Tous les clients disposent d'un unique point d'entrée public.
- Microservice Chatbot (NestJS) — Service conversationnel AI propulsé par Azure OpenAI (GPT-4o) via LangChain/LangGraph, avec RAG supporté par Elasticsearch pour la récupération de recettes et de connaissances.
- Microservice Santé (NestJS) — ingère et agrège les données de santé des wearables et les données manuelles (Apple Health, Health Connect) et fournit des analyses.
- AWS ECS Fargate exécute les trois services conteneurisés, chacun avec son propre dimensionnement CPU/mémoire et sa politique de scaling.
- L'Application Load Balancer termine le HTTPS et achemine le trafic vers le bon service en fonction du chemin.
- Couche de données partagée — MongoDB Atlas (stockage principal), Redis (cache/sessions), Elasticsearch (recherche), ActiveMQ (livraison asynchrone de notifications).
Fonctionnalités Clés
1. Modèle d'orchestrateur. Le serveur principal est le seul service exposé aux clients. Il authentifie chaque requête, puis effectue des appels internes de service à service — ainsi la topologie du backend reste privée et l'intégration client reste simple.
2. Appels de service à service authentifiés. La communication inter-services se fait en REST via un client HTTP partagé, sécurisée par des clés API bearer par service :
// Le serveur principal déléguant une requête AI au microservice chatbot const reply = await this.microserviceClient.post( this.chatbotApiKey, // clé bearer par service `${this.chatbotUrl}/chat`, { user, question, sessionId, attachment }, ); |
3. Scaling indépendant par charge de travail. Chaque service est une définition de tâche Fargate distincte avec son propre dimensionnement — le service chatbot, gourmand en mémoire, scale indépendamment de l'API principale légère, de sorte que les pics de trafic AI n'affament jamais les requêtes quotidiennes.
4. Service AI de taille optimale avec résilience intégrée. Le service chatbot alterne entre plusieurs clés Azure OpenAI, basculant automatiquement en cas de limites de débit ou d'erreurs — maintenant les fonctionnalités AI réactives sous charge.
5. Notifications via messagerie asynchrone. Parce que les files d'attente à délai ActiveMQ séparent les rappels et notifications basés sur le temps du flux de requêtes, la livraison des notifications n'entrave ni ne ralentit jamais le trafic API principal.
6. Déploiements reproductibles et isolés. D'ECR à ECS, chaque service est livré comme une image Docker propre. Une modification du service de santé ne fait que redéployer le service de santé — des livraisons rapides et à faible risque avec des mises à jour continues vérifiées.
7. Un contrat client cohérent. Le mobile (React Native) et le tableau de bord admin communiquent tous avec un unique point d'entrée équilibré en charge et HTTPS — la division interne en microservices leur est invisible.
RĂ©sultats
- De nos jours, les charges de travail pour les chatbots AI, les données de santé et les API principales scalent séparément ; aucune tâche ne peut détériorer les autres.
- Chaque service se déploie de manière autonome, transformant les livraisons à l'échelle de la plateforme, auparavant risquées, en mises à jour rapides et isolées.
- La capacité de calcul est dimensionnée spécifiquement pour chaque service, éliminant ainsi le sur-provisionnement d'un serveur unique.
- Un unique point d'entrée sécurisé et équilibré en charge simplifie l'intégration client tandis que le backend reste privé et modulaire.
Pile Technologique
NestJS · TypeScript · Node.js 20 · Azure OpenAI (GPT-4o) · LangChain · MongoDB Atlas · Redis · Elasticsearch · ActiveMQ · AWS ECS Fargate · Application Load Balancer · Amazon ECR · Docker
Autres Blogs
1. Comment nous mettons à l'échelle les charges de travail de traitement vidéo avec AWS ECS
2. Comment nous utilisons AWS ECR pour gérer et déployer des images conteneur
3. Comment nous utilisons AWS EC2 pour les charges de travail vidéo haute performance
