Cómo un proyecto de la facultad me hizo dejar de pensar en código y empezar a pensar en sistemas.

Cuando arrancamos TrainerOS con el Grupo VOX, yo tenía una idea bastante cómoda de lo que era "ser bueno programando": escribir código que funcione, que pase los tests y que se entienda. Lo que nunca había hecho era pararme frente a una pizarra en blanco y decidir qué construir antes de escribir una sola línea. Y ese, para mí, terminó siendo el verdadero trabajo final: el salto de programar a diseñar.

Este artículo es el relato honesto de ese salto. No voy a poner código —porque la verdad el código fue lo de menos—, sino las decisiones que tomamos, los errores de criterio que casi cometo, y lo que me llevo de todo esto.

El problema: el caos de las planillas de Excel

TrainerOS nació de una observación bastante simple. Los entrenadores personales manejan a decenas de alumnos con planillas de Excel y mensajes de WhatsApp. ¿El resultado? Caos: rutinas que quedan viejas, cobros que se pierden, cero control. Entonces pensamos una plataforma SaaS donde el entrenador paga una suscripción mensual y sus alumnos entran gratis a un panel móvil con la rutina del día.

Con esa idea en la cabeza, la tentación era abrir el editor y empezar a tirar endpoints. Me aguanté. Y ahí, sin darme cuenta, empezó lo que más aprendí.

Desafío 1: no hacer de mas con el MVP

El primer impulso de cualquiera que leyó tres artículos sobre microservicios es arrancar directamente con microservicios. Lo charlamos en el grupo y nos dimos cuenta de que era justo el error que la consigna nos pedía no cometer: usar una tecnología "porque está de moda" o "porque me gusta".

Para 50 o 100 entrenadores, lo correcto era un monolito modular en tres capas. Un solo despliegue, una sola base de datos PostgreSQL, un costo fijo de 7 a 16 dólares al mes. Elegimos Node.js porque el sistema es 95% leer y escribir datos, sin cálculos pesados, y porque usar TypeScript en el front y el back nos hacía ir mucho más rápido.

Pero la decisión que más me gusta de esa fase no fue elegir el monolito, sino diseñarlo modular a propósito, con límites internos bien marcados (Auth, Rutinas, Catálogo, Pagos). No fue casualidad: estábamos apostando a que esos módulos iban a ser los futuros microservicios. O sea, diseñar pensando en el problema que todavía no tenés, pero que sabés que se viene.

El primer aprendizaje, entonces: la arquitectura correcta no es la más avanzada, es la que va con el momento del negocio. Y conocer los límites de tu propia decisión —nosotros sabíamos exactamente cuándo el monolito iba a dejar de alcanzar— también es parte de diseñar bien.

Desafío 2: dejar que el negocio empuje la evolución

A los doce meses (en el escenario que planteamos), TrainerOS firma con dos cadenas de gimnasios y salta de 100 a 5.000 entrenadores con 120.000 alumnos. Ahí el monolito se rompe por tres lados: picos enormes de tráfico entre las 18 y las 21 h, tres equipos de desarrollo que se pisan al desplegar, y clientes B2B que piden SLA.

Migramos a microservicios. Pero el momento que de verdad me cambió la cabeza fue el Paso B.

Habíamos diseñado microservicios "tradicionales": cada servicio llamando a otro por HTTP/REST de forma síncrona. Y cuando lo dibujamos en el diagrama, el problema me saltó a la vista: si el servicio de Notificaciones estaba caído, asignar una rutina fallaba. ¿Por qué la tarea más importante del negocio dependía de la menos urgente? La disponibilidad del sistema entero terminaba siendo la multiplicación de las disponibilidades de cada parte, y multiplicar números menores a uno solo da números más chicos.

La solución fue dar vuelta la dependencia: pasar a una arquitectura orientada a eventos con un message broker (Pub/Sub). Los servicios dejan de llamarse entre sí y publican hechos de negocio: rutina.asignada, pago.confirmado, membresia.por_vencer. Notificaciones se entera cuando puede, y si se cae, los eventos esperan.

Ese cambio de mentalidad —de "A le pide algo a B" a "A avisa que pasó algo y el que tenga que escuchar, escucha"— fue lo más fuerte del proyecto. Es la diferencia entre acoplar y desacoplar, y no se ve en el código: se ve en el diagrama.

Desafío 3: escalar sin fundir el presupuesto

Con la base de eventos lista, la Fase 3 fue sobre robustez. Acá aprendí que escalar no es "poner más servidores y listo", sino saber qué parte del sistema duele y por qué.

El catálogo de ejercicios casi no cambia y se lee un montón de veces: va a una caché Redis con TTL de 24 horas. La rutina del día de cada alumno explota entre las 18 y las 21 h: caché con TTL de una hora, que se invalida cuando llega el evento rutina.asignada. Con eso, la mayoría de las lecturas del pico ni tocan PostgreSQL. La base se replica (las escrituras van a la primaria, las lecturas de reportes a las réplicas), y el auto-scaling horizontal agranda los pods de Rutinas a la tarde y los achica de madrugada.

El aprendizaje de criterio acá: cada decisión de escalabilidad tiene que responder a un patrón de carga concreto. No cacheamos "porque sí"; cacheamos lo que se lee mucho y cambia poco. Esa pregunta es la que separa al que copia una arquitectura del que la entiende.

Desafío 4: la infraestructura también es diseño

La Fase 4 fue la que más me sacó de la zona de confort, porque acá ya no hay nada de "programar". Elegimos Google Cloud porque Pub/Sub ya era nuestro broker, GKE es Kubernetes de referencia y Cloud SQL nos daba alta disponibilidad casi sin configurar.

Armamos cuatro ambientes (Desa, QA, UAT, Prod), cada uno en su propio proyecto de GCP para aislar permisos, redes y facturación. La regla que más me copó: siempre se promueve el mismo artefacto —la imagen Docker etiquetada por commit— y lo único que cambia entre ambientes es la configuración. Lo que probaste en QA es exactamente lo que corre en Prod.

Toda la infraestructura quedó como código en Terraform, y cambiarla sigue el mismo flujo que el código: pull request, plan, aprobación, apply. Y armar la tabla de costos —dimensionar nodos, base, caché, broker— fue donde más claro vi de qué se trata "el criterio del desarrollador": con 5.000 entrenadores pagando 15 dólares, los ~520 de infraestructura productiva son menos del 1% de los ingresos. Eso no es un dato técnico, es un argumento de negocio. Y un CTO compra argumentos de negocio.

Desafío 5: meter IA sin romper todo

La última fase fue integrar un LLM como asistente del entrenador: borradores de rutina, resúmenes de progreso, clasificación de feedback. La regla la tuve clarísima desde el diagrama: una llamada a un LLM externo tarda entre 2 y 60 segundos y puede fallar; nunca puede bloquear el request del usuario ni atar mi disponibilidad a la del proveedor.

Lo lindo fue darme cuenta de que no hacía falta inventar nada nuevo: reusé el backbone de eventos. El cliente recibe un 202 Accepted con un job_id al toque, el trabajo va a una cola, y unos workers dedicados lo procesan con timeouts, reintentos, circuit breaker y dead-letter queue. La IA asiste, nunca publica sola. Diseñar bien al principio me terminó devolviendo el favor al final.

Lo que me llevo: de programar a diseñar

Si tuviera que resumirlo en una frase: programar es resolver el problema que tenés enfrente; diseñar es decidir qué problemas vas a tener y prepararte para ellos.

Programando, la pregunta es "¿esto funciona?". Diseñando, las preguntas son otras: ¿esto escala?, ¿cuánto sale?, ¿qué pasa si esta pieza no anda?, ¿pueden los tres equipos trabajar sin pisarse entre ellos?, ¿es esta la decision correcta para este momento del negocio? Ninguna de esas se contesta con un test aprobado.

¿Dónde se usa esto en la industria real?

Lo más interesante es que el camino que recorrió TrainerOS no es exclusivo de una app de fitness. Es la historia de casi cualquier SaaS que crece:

• Cualquier plataforma multitenant —turnos médicos, gestión de restaurantes, edtech— arranca como monolito y choca con la misma presión de escalar cuando entra un cliente grande.
• Sistemas con picos predecibles —ticketing, delivery, fintech a fin de mes— viven o mueren según la estrategia de caché y auto-scaling que vimos en la Fase 3.
• La arquitectura orientada a eventos es hoy lo más común en e-commerce, logística y banca, justamente por el desacople que nos salvó las notificaciones.
• El patrón asíncrono para IA —responder rápido, procesar en segundo plano, protegerse con circuit breakers— es básicamente cómo cualquier producto serio integra LLMs sin quedar atado a un proveedor.

Termino este trabajo convencido de algo: el código se aprende rápido y queda viejo rápido. El criterio para decidir qué construir, cuándo y por qué es lo que de verdad separa a un desarrollador de un programador. Y ese criterio no se escribe en un editor: se dibuja en una pizarra, se discute con el equipo y se justifica frente a quien va a pagar.

Lautaro David Martinez Naglieri — Grupo VOX. Trabajo Final Integrador, Desarrollo de Aplicaciones Web, 2026.