Cómo construimos GlucoTracker: Arquitectura monolítica en AWS paso a paso

Diego Laguna — Mon, 08 Jun 2026 01:31:29 +0000

Hoy quiero compartir con ustedes los detalles técnicos detrás del proyecto GlucoTracker.

Cuando creamos aplicaciones desde cero, a menudo nos enfrentamos a la decisión de cómo y dónde desplegarlas. En este post, quiero llevarlos a través de este proyecto, desde el problema que buscaba resolver hasta por qué decidí apostar por una arquitectura tradicional en la nube con AWS, incluyendo costos, desafíos y aprendizajes.

¿Por qué nació GlucoTracker?

En Bolivia, muchas personas con diabetes todavía controlan sus niveles de glucosa de forma manual. Esto significa que los datos están dispersos, a veces en papel, lo que hace casi imposible detectar a tiempo valores fuera de los rangos normales o compartir esta información rápidamente con un médico. Los sistemas tradicionales suelen carecer de escalabilidad y no ofrecen un almacenamiento seguro o en tiempo real.

¿Qué es exactamente GlucoTracker?

GlucoTracker es un sistema de monitoreo de glucosa en la nube. Permite:

Que los pacientes registren sus niveles de manera segura.
Que los médicos puedan visualizar el historial de sus pacientes en tiempo real.
Generar alertas automáticas cuando los valores registrados están fuera de los rangos normales.
Manejar distintos roles: Soporte, Paciente y Médico.

Arquitectura del sistema en AWS

Para el MVP (Producto Mínimo Viable), el objetivo no era solo tener una aplicación que funcionara, sino validar una arquitectura en la nube que fuera segura y accesible. Optamos por una arquitectura monolítica contenerizada. En lugar de microservicios, decidimos mantener el control del entorno de ejecución.

El flujo es bastante directo:

El usuario accede al Frontend (desarrollado en Angular) a través de su navegador.
El Frontend se comunica vía HTTP con nuestro Backend (construido con Node.js y Express).
Ambos, Frontend y Backend, viven dentro de contenedores orquestados con Docker Compose en una misma instancia virtual.
Dependiendo de la petición, el Backend consulta la base de datos relacional o interactúa con nuestro almacenamiento de archivos.

Servicios de AWS utilizados

Para garantizar la disponibilidad y separar el “estado” de la aplicación del “cómputo", utilizamos los siguientes servicios:

Amazon EC2 (t3.small): Utilizamos una instancia virtual para alojar los contenedores Docker del frontend y backend. Elegimos EC2 porque nos da un control total sobre el entorno y facilita mucho el despliegue gracias a Docker.
Amazon RDS (PostgreSQL): Aquí guardamos usuarios, registros de glucosa y alertas. Separar la base de datos de la instancia EC2 garantiza que si el servidor web cae, los datos médicos siguen intactos y disponibles.
Amazon S3: Lo usamos para guardar fotos de perfil de los usuarios y documentos sensibles de los médicos, como matrículas profesionales y carnets. En lugar de saturar el disco de la EC2, S3 nos da una durabilidad.
AWS IAM y Security Groups: La capa de seguridad. A la instancia EC2 se le asignó un IAM Role que le da permisos estrictos (solo PutObject y DeleteObject) para interactuar con S3, evitando tener que quemar credenciales en el código. Además, la base de datos en RDS está protegida por un Security Group que solo acepta tráfico por el puerto 5432 proveniente exclusivamente de la EC2.

Dinero: Costos del sistema

Como desarrolladores, siempre nos asusta dejar un servicio prendido y amanecer con una factura de miles de dólares. Para este MVP en operación 24/7 (región N. Virginia), el costo estimado mensual es de $39.87 USD.

Amazon RDS: $32.23 USD/mes (instancia db.t4g.micro con 20GB SSD).
Amazon EC2: $7.52 USD/mes.
Amazon S3: $0.12 USD/mes (estimando unos 5GB en la capa Standard).

Estrategia de ahorro: Como estamos en fase de MVP y no requerimos alta disponibilidad extrema (High Availability), configuramos la base de datos RDS en modo Single-AZ. Esto reduce el costo del servicio de base de datos a la mitad.

Beneficios de desplegar en AWS de esta manera

Cero dolores de cabeza con el entorno: Al usar Docker en EC2, garantizamos que el código que corre en la máquina local de los desarrolladores es exactamente el mismo que corre en producción.
Independencia del estado: Si mañana decidimos destruir la instancia EC2 y levantar una nueva, no perdemos nada. La información crítica vive segura en RDS y los archivos médicos en S3.

Retos y aprendizajes (Trade-offs)

No todo fue un camino de rosas. Hubo decisiones difíciles que tomar:

De Supabase a RDS: Al principio, el proyecto usaba Supabase, pero decidimos migrar todo a Amazon RDS con PostgreSQL. Tuvimos que invertir tiempo reescribiendo la lógica de conexión y los endpoints en el backend. A cambio, ganamos independencia tecnológica, control absoluto sobre el motor de base de datos y la capacidad de optimizar consultas SQL nativas.
Monolito vs Serverless: Desplegar en contenedores EC2 nos dio costos fijos predecibles (sin sustos por picos de consumo) y mucho control. Sin embargo, el trade-off es que nuestra escalabilidad está acoplada. Si el tráfico del frontend se dispara, tendremos que escalar verticalmente toda la máquina EC2, en lugar de poder escalar servicios de forma independiente.

Conclusión

Construir GlucoTracker y llevarlo a AWS fue un ejercicio fantástico de arquitectura cloud tradicional. Comprobamos que no siempre necesitas la arquitectura más compleja o de moda para tener un sistema robusto, seguro y escalable.

DEV Community: Diego Laguna

Cómo construimos GlucoTracker: Arquitectura monolítica en AWS paso a paso