Un único backend estaba siendo superado por un negocio en expansión de salud y nutrición. El tráfico del chatbot de AI, la ingesta intensiva de datos de dispositivos wearables y las solicitudes diarias de API competían por los mismos recursos, lo que hacía que el sistema fuera difícil de escalar y arriesgado de desplegar. Lo rediseñamos en servicios enfocados, desplegables de forma independiente, orquestados detrás de un único API gateway, ejecutándose en AWS.
El Desafío
- Una única base de código manejando todas las tareas. Un flujo de trabajo incluía gestión de usuarios, inferencia del chatbot de AI, recetas y análisis de datos de salud. Un pico en cualquier área degradaba toda la plataforma, y cada cambio significaba volver a desplegar todo el sistema.
- Perfiles de recursos extremadamente dispares. Las solicitudes del chatbot impulsado por LLM consumen mucha CPU y memoria y son intermitentes; la ingesta de datos de dispositivos wearables es intensiva en escritura y continua; las API CRUD principales son ligeras y constantes. Dimensionar un solo servidor para los tres significaba pagar de más por algunas cargas de trabajo y privar de recursos a otras.
- Escalado y despliegue independientes. El equipo necesitaba escalar la carga de trabajo de AI sin afectar la API principal, y lanzar cambios en un dominio sin poner en riesgo los demás.
Un único punto de entrada seguro. A pesar de los múltiples servicios de backend, los clientes (móviles, web, admin) necesitaban una superficie consistente y autenticada para comunicarse, sin exponer la topología interna del servicio al mundo exterior.
Nuestra Solución
Dividimos la plataforma en tres servicios NestJS enfocados detrás de un AWS Application Load Balancer, con el servidor principal actuando como un API gateway y orquestador. Es propietario de la autenticación y los dominios centrales, y delega el trabajo especializado a los microservicios de chatbot y salud a través de REST autenticado. Una capa compartida de datos y mensajería mantiene los servicios débilmente acoplados pero consistentes.

Arquitectura
- Servidor Principal (NestJS) — API gateway y orquestador: autenticación, usuarios, objetivos, recetas, programación y notificaciones. Todos los clientes tienen un único punto de entrada público.
- Microservicio de Chatbot (NestJS) — Servicio conversacional de AI impulsado por Azure OpenAI (GPT-4o) a través de LangChain/LangGraph, con RAG respaldado por Elasticsearch para la recuperación de recetas y conocimientos.
- Microservicio de Salud (NestJS) — ingesta y agrega datos de salud manuales y de dispositivos wearables (Apple Health, Health Connect) y ofrece análisis.
- AWS ECS Fargate ejecuta los tres servicios en contenedores, cada uno con su propio dimensionamiento de CPU/memoria y política de escalado.
- Application Load Balancer termina HTTPS y enruta el tráfico según la ruta al servicio correcto.
- Capa de datos compartida — MongoDB Atlas (almacén principal), Redis (caché/sesiones), Elasticsearch (búsqueda), ActiveMQ (entrega asíncrona de notificaciones).
Características Clave
1. Patrón de orquestador. El servidor principal es el único servicio expuesto a los clientes. Autentica cada solicitud y luego realiza llamadas internas de servicio a servicio, de modo que la topología del backend permanece privada y la integración del cliente sigue siendo sencilla.
2. Llamadas de servicio a servicio autenticadas. La comunicación entre servicios es REST a través de un cliente HTTP compartido, asegurada con claves API bearer por servicio:
// 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. Escalado independiente por carga de trabajo. Cada servicio es una definición de tarea de Fargate separada con su propio dimensionamiento: el servicio de chatbot, intensivo en memoria, escala independientemente de la API principal ligera, por lo que los picos de tráfico de AI nunca privan de recursos a las solicitudes diarias.
4. Servicio de AI de tamaño adecuado con resiliencia incorporada. El servicio de chatbot rota entre múltiples claves de Azure OpenAI, realizando un failover automático en caso de límites de tasa o errores, manteniendo las características de AI responsivas bajo carga.
5. Notificaciones mediante mensajería asíncrona. Dado que las colas de retardo de ActiveMQ separan los recordatorios y avisos basados en el tiempo del flujo de solicitudes, la entrega de notificaciones nunca obstaculiza ni ralentiza el tráfico principal de la API.
6. Despliegues repetibles y aislados. Desde ECR hasta ECS, cada servicio se entrega como su propia imagen Docker. Una modificación al servicio de salud simplemente vuelve a desplegar el servicio de salud—lanzamientos rápidos y de bajo riesgo con actualizaciones progresivas que son verificadas.
7. Un contrato de cliente consistente. Mobile (React Native) y el panel de administración se comunican con un único punto de entrada balanceado y HTTPS; la división interna en microservicios es invisible para ellos.
Resultados
- Actualmente, las cargas de trabajo para chatbots de AI, datos de salud y API principales escalan por separado; ninguna tarea puede deteriorar a las otras.
- Cada servicio se despliega de forma independiente, convirtiendo los lanzamientos arriesgados de toda la plataforma en actualizaciones rápidas y aisladas.
- La computación se ajusta al tamaño adecuado por servicio, eliminando el sobreaprovisionamiento de un servidor de talla única.
- Un único punto de entrada seguro y balanceado mantiene la integración del cliente sencilla mientras el backend permanece privado y modular.
Pila Tecnológica
NestJS · TypeScript · Node.js 20 · Azure OpenAI (GPT-4o) · LangChain · MongoDB Atlas · Redis · Elasticsearch · ActiveMQ · AWS ECS Fargate · Application Load Balancer · Amazon ECR · Docker
Otros Blogs
1. Cómo Escalamos Cargas de Trabajo de Procesamiento de Video con AWS ECS
2. Cómo Usamos AWS ECR para Administrar y Desplegar Imágenes de Contenedores
3. Cómo Usamos AWS EC2 para Cargas de Trabajo en Video de Alto Rendimiento

