Isang backend lang ang hindi na sapat para sa lumalaking negosyo ng kalusugan at nutrisyon. Ang AI chatbot traffic, malaking pagpasok ng wearable-data, at pang-araw-araw na API requests ay lahat naglalaban para sa iisang resource — ginagawang mahirap i-scale ang system at mapanganib i-deploy. Muli naming inarkitekto ito sa nakatutok, independiyenteng maide-deploy na mga serbisyo na pinangangasiwaan sa likod ng iisang API gateway, na tumatakbo sa AWS.
Ang Hamon
- Isang codebase na humahawak sa lahat ng gawain. Isang workflow ang kasama ang user management, AI chatbot inference, mga recipe, at health data analytics. Ang pagtaas ng load sa isang area ay nagpapababa ng performance ng buong platform, at bawat pagbabago ay nangangahulugang pag-redeploy ng lahat.
- Lubhang magkakaibang resource profile. Ang mga LLM-powered chatbot request ay malakas sa CPU at memory at pabago-bago ang paggamit; ang pagpasok ng wearable-data ay write-heavy at tuloy-tuloy; ang core CRUD APIs ay magaan at constante. Ang pag-size ng iisang server para sa tatlo ay nangangahulugang sobra ang bayad para sa ilang workloads at kulang para sa iba.
- Independiyenteng pag-scale at deployment. Kailangan ng team na i-scale ang AI workload nang hindi hinahawakan ang core API, at magpadala ng mga pagbabago sa isang domain nang hindi inilalagay sa panganib ang iba.
Isang solong, ligtas na pasukan. Sa kabila ng maraming backend services, kailangan ng mga client (mobile, web, admin) ng isang consistent, authenticated na interface para makipag-usap — nang hindi lumalabas ang internal service topology sa labas.
Ang Aming Solusyon
Hinati namin ang platform sa tatlong nakatutok na NestJS services sa likod ng isang AWS Application Load Balancer, kung saan ang pangunahing server ay nagsisilbing API gateway at orchestrator. Hawak nito ang authentication at core domains, at ipinapasa ang espesyalisadong trabaho sa chatbot at health microservices sa pamamagitan ng authenticated REST. Pinapanatili ng shared data at messaging layer ang mga serbisyo na loosely coupled ngunit consistent.
Arkitektura
- Main Server (NestJS) — API gateway at orchestrator: authentication, mga user, mga layunin, mga recipe, scheduling, at mga notification. Lahat ng client ay may iisang public entry point.
- Chatbot Microservice (NestJS) — AI conversational service na pinapagana ng Azure OpenAI (GPT-4o) sa pamamagitan ng LangChain/LangGraph, na may Elasticsearch-backed RAG para sa recipe at knowledge retrieval.
- Health Microservice (NestJS) — nag-iingest at nag-a-aggregate ng wearable at manual health data (Apple Health, Health Connect) at nagbibigay ng analytics.
- Pinapatakbo ng AWS ECS Fargate ang tatlong containerized services, bawat isa ay may sariling CPU/memory sizing at scaling policy.
- Tinatapos ng Application Load Balancer ang HTTPS at path-routes traffic sa tamang serbisyo.
- Shared data layer — MongoDB Atlas (primary store), Redis (cache/sessions), Elasticsearch (search), ActiveMQ (async notification delivery).
CI/CD — Ang Docker multi-stage builds ay itinulak sa Amazon ECR, inilunsad sa ECS bilang rolling updates.
Mga Pangunahing Tampok
1. Orchestrator pattern. Ang main server ang tanging serbisyo na nakalantad sa mga client. Ina-authenticate nito ang bawat request, pagkatapos ay gumagawa ng internal service-to-service calls — kaya nananatiling pribado ang backend topology at simple ang client integration.
2. Authenticated service-to-service calls. Ang inter-service communication ay REST sa pamamagitan ng shared HTTP client, na secure gamit ang per-service bearer API keys:
// Main server delegating an AI request to the chatbot microservice const reply = await this.microserviceClient.post( this.chatbotApiKey, // per-service bearer key `${this.chatbotUrl}/chat`, { user, question, sessionId, attachment }, ); |
3. Independiyenteng pag-scale sa bawat workload. Ang bawat serbisyo ay isang hiwalay na Fargate task definition na may sariling sizing — ang memory-heavy na chatbot service ay nag-i-scale nang independiyente sa lightweight core API, kaya ang mga AI traffic spike ay hindi kailanman nagpapabagal sa pang-araw-araw na requests.
4. Right-sized AI service na may built-in na resilience. Ang chatbot service ay umiikot sa maraming Azure OpenAI keys, awtomatikong nagfa-fail over sa rate limits o errors — pinapanatiling responsive ang mga AI features sa ilalim ng load.
5. Notifications sa pamamagitan ng asynchronous messaging. Dahil ang ActiveMQ delay queues ay naghihiwalay ng time-based nudges at reminders mula sa request stream, ang paghahatid ng notification ay hindi kailanman humahadlang o nagpapabagal sa core API traffic.
6. Repeatable, isolated deployments. Mula ECR hanggang ECS, ang bawat serbisyo ay inilalabas bilang sarili nitong Docker image. Ang pagbabago sa health service ay muling nagde-deploy lamang ng health service—mabilis, mababang-risk na pagpapalabas na may rolling updates na may health-check.
7. Isang consistent na client contract. Ang Mobile (React Native) at ang admin dashboard ay lahat nakikipag-usap sa isang load-balanced, HTTPS entry point — ang internal na paghahati sa microservices ay hindi nakikita sa kanila.
Mga Resulta
- Sa kasalukuyan, ang mga workload para sa AI chatbots, health data, at core APIs ay nag-i-scale nang hiwalay; walang gawain ang maaaring magpababa ng performance ng iba.
- Ang bawat serbisyo ay nagde-deploy nang mag-isa, ginagawang mabilis at isolated na update ang mga mapanganib na platform-wide release.
- Ang compute ay right-sized bawat serbisyo, na nagtatanggal ng over-provisioning ng isang one-size-fits-all server.
- Ang isang solong secure, load-balanced entry point ay pinapanatiling simple ang client integration habang nananatiling pribado at modular ang backend.
Technology Stack
NestJS · TypeScript · Node.js 20 · Azure OpenAI (GPT-4o) · LangChain · MongoDB Atlas · Redis · Elasticsearch · ActiveMQ · AWS ECS Fargate · Application Load Balancer · Amazon ECR · Docker
Other Blogs
1. How We Scale Video Processing Workloads with AWS ECS
2. How We Use AWS ECR to Manage and Deploy Container Images
3. How We Use AWS EC2 for Workloads in High-Performance Video
