Et enkelt backend-system var blevet for lille for en voksende sundheds- og ernæringsvirksomhed. AI chatbot-trafik, stor indtagelse af data fra wearables og daglige API-anmodninger konkurrerede alle om de samme ressourcer – hvilket gjorde systemet svært at skalere og risikabelt at implementere. Vi re-arkitekturede det til fokuserede, uafhængigt implementerbare tjenester orkestreret bag en enkelt API gateway, kørende på AWS.
Udfordringen
- Én codebase håndterede alle opgaver. Én workflow inkluderede brugerstyring, AI chatbot-inferens, opskrifter og sundhedsdataanalyse. En spidsbelastning inden for et enkelt område forringede hele platformen, og enhver ændring betød genimplementering af det hele.
- Ekstremt forskellige ressourceprofiler. LLM-drevne chatbot-anmodninger er CPU- og hukommelsestunge og opstår i byger; indtagelse af data fra wearables er skriveintensiv og kontinuerlig; kerne CRUD API'er er lette og konstante. At dimensionere én server til alle tre betød at overbetale for nogle workloads og udsulte andre.
- Uafhængig skalering og implementering. Holdet havde brug for at skalere AI-workloaden uden at røre kerne API'en og levere ændringer til ét domæne uden at risikere de andre.
Et enkelt, sikkert indgangspunkt. På trods af flere backend-tjenester havde klienter (mobil, web, admin) brug for en konsistent, autentificeret grænseflade at kommunikere med – uden at blotlægge intern servicetopologi for omverdenen.
Vores løsning
Vi opdelte platformen i tre fokuserede NestJS-tjenester bag en AWS Application Load Balancer, hvor hovedserveren fungerede som en API gateway og orchestrator. Den håndterer autentificering og kerne-domæner og delegerer specialiseret arbejde til chatbot- og sundhedsmicroservices via autentificeret REST. Et delt data- og messaging-lag holder tjenesterne løst koblet, men konsistente.
Arkitektur
- Main Server (NestJS) — API gateway og orchestrator: autentificering, brugere, mål, opskrifter, tidsplanlægning og notifikationer. Alle klienter har et enkelt offentligt indgangspunkt.
- Chatbot Microservice (NestJS) — AI-samtaletjeneste drevet af Azure OpenAI (GPT-4o) via LangChain/LangGraph, med Elasticsearch-understøttet RAG til opskrifts- og videnshentning.
- Health Microservice (NestJS) — indtager og aggregerer wearable- og manuel sundhedsdata (Apple Health, Health Connect) og leverer analyser.
- AWS ECS Fargate kører de tre containeriserede tjenester, hver med sin egen CPU/memory-dimensionering og skaleringspolitik.
- Application Load Balancer afslutter HTTPS og path-router trafikken til den rigtige tjeneste.
- Delt datalag — MongoDB Atlas (primær lagring), Redis (cache/sessioner), Elasticsearch (søgning), ActiveMQ (asynkron notifikationslevering).
CI/CD — Docker multi-stage builds skubbet til Amazon ECR, implementeret til ECS som rolling updates.
Nøglefunktioner
1. Orchestrator-mønster. Hovedserveren er den eneste tjeneste, der eksponeres for klienter. Den autentificerer hver anmodning og foretager derefter interne service-til-service kald – så backend-topologien forbliver privat, og klientintegrationen forbliver enkel.
2. Autentificerede service-til-service kald. Inter-service kommunikation er REST over en delt HTTP client, sikret med bearer API keys per tjeneste:
// Hovedserver delegerer en AI-anmodning til chatbot microservice const reply = await this.microserviceClient.post( this.chatbotApiKey, // bearer key per tjeneste `${this.chatbotUrl}/chat`, { user, question, sessionId, attachment }, ); |
3. Uafhængig skalering per workload. Hver tjeneste er en separat Fargate task definition med sin egen dimensionering – den hukommelsestunge chatbot-tjeneste skalerer uafhængigt af den letvægts kerne API, så AI-trafikspidser aldrig sulter daglige anmodninger.
4. Rigtigt dimensioneret AI-tjeneste med indbygget robusthed. Chatbot-tjenesten roterer mellem flere Azure OpenAI-nøgler og fejler automatisk over ved rate limits eller fejl – hvilket holder AI-funktioner responsive under belastning.
5. Notifikationer via asynkron messaging. Da ActiveMQ delay queues adskiller tidsbaserede nudges og påmindelser fra anmodningsstrømmen, hæmmer eller forsinker notifikationslevering aldrig kerne API-trafik.
6. Gentagelige, isolerede implementeringer. Fra ECR til ECS leveres hver tjeneste som et eget Docker image. En ændring i sundhedstjenesten genimplementerer blot sundhedstjenesten – hurtige, lavrisiko-udgivelser med rolling updates, der er sundhedskontrollerede.
7. Én konsistent klientkontrakt. Mobil (React Native) og admin-dashboardet taler alle til et enkelt load-balanced, HTTPS-indgangspunkt – den interne opdeling i microservices er usynlig for dem.
Resultater
- I dag skalerer workloads for AI chatbots, sundhedsdata og kerne API'er separat; ingen opgave kan forringe de andre.
- Hver tjeneste implementeres for sig selv, hvilket omdanner risikable platformsdækkende udgivelser til hurtige, isolerede opdateringer.
- Compute er korrekt dimensioneret per tjeneste, hvilket eliminerer over-provisionering af en one-size-fits-all server.
- Et enkelt sikkert, load-balanced indgangspunkt holder klientintegrationen enkel, mens backend forbliver privat og modulær.
Teknologistack
NestJS · TypeScript · Node.js 20 · Azure OpenAI (GPT-4o) · LangChain · MongoDB Atlas · Redis · Elasticsearch · ActiveMQ · AWS ECS Fargate · Application Load Balancer · Amazon ECR · Docker
Andre blogs
1. Sådan skalerer vi video processing workloads med AWS ECS
2. Sådan bruger vi AWS ECR til at administrere og implementere container images
3. Sådan bruger vi AWS EC2 til workloads inden for højtydende video
