Sebuah backend tunggal mulai kewalahan seiring berkembangnya bisnis kesehatan dan nutrisi. Lalu lintas chatbot AI, penyerapan data perangkat wearable yang masif, dan permintaan API harian semuanya bersaing untuk sumber daya yang sama — membuat sistem sulit diskalakan dan berisiko untuk di-deploy. Kami mere-arsitektur ulang menjadi layanan-layanan yang terfokus, dapat di-deploy secara independen, yang diorkestrasi di balik satu API gateway, berjalan di AWS.
Tantangan
- Satu codebase menangani semua tugas. Satu alur kerja mencakup manajemen pengguna, inferensi chatbot AI, resep, dan analitik data kesehatan. Lonjakan di salah satu area akan menurunkan kinerja seluruh platform, dan setiap perubahan berarti harus melakukan redeploy keseluruhan sistem.
- Profil sumber daya yang sangat berbeda. Permintaan chatbot bertenaga LLM sangat memakan CPU dan memori serta bersifat bursty; penyerapan data perangkat wearable bersifat write-heavy dan berkelanjutan; API CRUD inti bersifat ringan dan konstan. Menentukan ukuran satu server untuk ketiga-tiganya berarti membayar lebih untuk beberapa beban kerja dan membuat yang lain kekurangan sumber daya.
- Skalabilitas dan deployment independen. Tim perlu menskalakan beban kerja AI tanpa menyentuh API inti, dan mengirimkan perubahan ke satu domain tanpa membahayakan yang lain.
Satu titik masuk yang aman. Meskipun memiliki beberapa layanan backend, klien (seluler, web, admin) memerlukan satu antarmuka yang konsisten dan terautentikasi untuk berkomunikasi — tanpa membocorkan topologi layanan internal ke dunia luar.
Solusi Kami
Kami membagi platform menjadi tiga layanan NestJS yang terfokus di belakang AWS Application Load Balancer, dengan server utama berfungsi sebagai API gateway dan orchestrator. Server ini memiliki autentikasi dan domain inti, serta mendelegasikan pekerjaan khusus ke chatbot dan microservices kesehatan melalui REST terautentikasi. Lapisan data dan pesan bersama menjaga layanan tetap loosely coupled namun konsisten.
Arsitektur
- Main Server (NestJS) — API gateway dan orchestrator: autentikasi, pengguna, tujuan, resep, penjadwalan, dan notifikasi. Semua klien memiliki satu titik masuk publik.
- Chatbot Microservice (NestJS) — layanan percakapan AI yang ditenagai oleh Azure OpenAI (GPT-4o) melalui LangChain/LangGraph, dengan RAG yang didukung Elasticsearch untuk pengambilan resep dan pengetahuan.
- Health Microservice (NestJS) — menyerap dan mengagregasi data kesehatan wearable dan manual (Apple Health, Health Connect) serta menyajikan analitik.
- AWS ECS Fargate menjalankan ketiga layanan yang dikontainerisasi, masing-masing dengan ukuran CPU/memori dan kebijakan skalanya sendiri.
- Application Load Balancer menghentikan HTTPS dan mengarahkan lalu lintas berdasarkan path ke layanan yang tepat.
- Lapisan data bersama — MongoDB Atlas (penyimpanan utama), Redis (cache/sesi), Elasticsearch (pencarian), ActiveMQ (pengiriman notifikasi asinkron).
CI/CD — Build Docker multi-stage didorong ke Amazon ECR, di-deploy ke ECS sebagai rolling updates.
Fitur Utama
1. Pola Orchestrator. Server utama adalah satu-satunya layanan yang terekspos ke klien. Ini mengautentikasi setiap permintaan, kemudian melakukan panggilan layanan-ke-layanan internal — sehingga topologi backend tetap privat dan integrasi klien tetap sederhana.
2. Panggilan layanan-ke-layanan yang terautentikasi. Komunikasi antar-layanan adalah REST melalui klien HTTP bersama, diamankan dengan bearer API keys per layanan:
// 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. Skalabilitas independen per beban kerja. Setiap layanan adalah definisi tugas Fargate terpisah dengan ukurannya sendiri — layanan chatbot yang memakan banyak memori diskalakan secara independen dari API inti yang ringan, sehingga lonjakan lalu lintas AI tidak akan pernah membuat permintaan harian kelaparan sumber daya.
4. Layanan AI berukuran tepat dengan resiliensi bawaan. Layanan chatbot berputar di antara beberapa Azure OpenAI keys, secara otomatis melakukan failover pada batas laju atau kesalahan — menjaga fitur AI tetap responsif di bawah beban.
5. Notifikasi melalui perpesanan asinkron. Karena antrean tunda ActiveMQ memisahkan dorongan dan pengingat berbasis waktu dari aliran permintaan, pengiriman notifikasi tidak pernah menghambat atau memperlambat lalu lintas API inti.
6. Deployment yang berulang dan terisolasi. Dari ECR hingga ECS, setiap layanan dikirim sebagai Docker image-nya sendiri. Modifikasi pada layanan kesehatan hanya akan melakukan redeploy layanan kesehatan — rilis cepat dan berisiko rendah dengan rolling updates yang diperiksa kesehatannya.
7. Satu kontrak klien yang konsisten. Mobile (React Native) dan dashboard admin semuanya berbicara ke satu titik masuk HTTPS yang seimbang bebannya — pembagian internal menjadi microservices tidak terlihat oleh mereka.
Hasil
- Saat ini, beban kerja untuk chatbot AI, data kesehatan, dan API inti diskalakan secara terpisah; tidak ada tugas yang dapat memperburuk kinerja yang lain.
- Setiap layanan di-deploy secara mandiri, mengubah rilis seluruh platform yang berisiko menjadi pembaruan yang cepat dan terisolasi.
- Komputasi diukur dengan tepat per layanan, menghilangkan penyediaan berlebihan dari server yang serba cocok.
- Satu titik masuk yang aman dan seimbang bebannya menjaga integrasi klien tetap sederhana sementara backend tetap privat dan modular.
Tumpukan Teknologi
NestJS · TypeScript · Node.js 20 · Azure OpenAI (GPT-4o) · LangChain · MongoDB Atlas · Redis · Elasticsearch · ActiveMQ · AWS ECS Fargate · Application Load Balancer · Amazon ECR · Docker
Blog Lainnya
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
