Durante mucho tiempo asocié el desarrollo de software con programar funcionalidades: crear entidades, armar controladores, conectar una base de datos, validar formularios y hacer que una aplicación responda correctamente.
Sin embargo, durante el Trabajo Final de la asignatura Desarrollo de Aplicaciones Web, entendí que programar es solo una parte del problema. El verdadero desafío aparece antes de escribir código: decidir qué arquitectura conviene, por qué conviene, cuánto cuesta, qué riesgos resuelve y qué complejidad agrega.
El trabajo consistió en diseñar un sistema de gestión clínica que comenzaba como un MVP para una única clínica y evolucionaba progresivamente hacia una plataforma SaaS multi-tenant. Aunque fue un proyecto académico, el ejercicio nos obligó a pensar como si estuviéramos tomando decisiones técnicas en un contexto real: con restricciones de negocio, costos, equipo, seguridad, datos sensibles y crecimiento futuro.
La principal enseñanza fue: la mejor arquitectura es la que responde mejor al momento del producto.
El primer desafío: no sobrediseñar desde el inicio
Cuando empezamos a pensar el sistema, la tentación era ir directamente a una arquitectura compleja: microservicios, eventos, colas, Kubernetes, múltiples bases de datos y despliegues independientes.
Pero al analizar el escenario inicial, esa decisión no tenía sentido. El sistema comenzaba para una sola clínica, con un presupuesto reducido y con requisitos todavía en etapa de validación. En ese contexto, arrancar con microservicios hubiera agregado más problemas que beneficios: comunicación entre servicios, contratos, versionado, observabilidad distribuida, debugging más difícil y mayor costo de infraestructura.
Por eso, una de las decisiones más importantes fue comenzar con una arquitectura en capas, desplegada como un único proceso. Esta elección permitió separar responsabilidades sin asumir desde el principio la complejidad de un sistema distribuido.
La capa de presentación se encargaba de la API, los controladores, DTOs y autenticación. La capa de aplicación concentraba casos de uso, como gestionar pacientes, reservar turnos o registrar historias clínicas. La capa de infraestructura resolvía la persistencia, el acceso a PostgreSQL, los repositorios y la integración con WhatsApp.
Este enfoque nos mostró que un monolito no necesariamente es una mala decisión. Puede ser una muy buena arquitectura si está bien organizado, si mantiene límites claros entre módulos y si responde al tamaño real del problema.
Lo importante fue entender que no estábamos eligiendo “algo simple” por falta de conocimiento, sino porque era la opción más razonable para la primera etapa.
Diseñar también es anticipar sin complicar
Otro aprendizaje importante fue que no todas las decisiones futuras cuestan lo mismo. Algunas son baratas de tomar al inicio y muy caras de agregar después.
Por ejemplo, aunque el sistema empezara con una sola clínica, decidimos incluir TenantId _desde el modelo de datos inicial. Puede parecer innecesario, porque hay un único _tenant. Pero si más adelante el sistema evoluciona a SaaS, agregar multi-tenancy sobre tablas que nunca fueron pensadas para eso podía convertirse en una migración riesgosa.
Lo mismo ocurrió con Docker. Aunque el MVP pudiera ejecutarse de una forma más simple, containerizar _la aplicación tempranamente hacía más fácil moverla después a otra infraestructura.
También definimos una abstracción para el envío de mensajes de WhatsApp. En lugar de acoplar todo el sistema directamente a un proveedor, una interfaz como _IWhatsAppSender permitía cambiar la implementación, mockear envíos en desarrollo o reemplazar el proveedor en el futuro.
Ahí entendí una diferencia clave entre programar y diseñar: programar resuelve el problema inmediato; diseñar intenta resolverlo sin cerrar puertas para un futuro.
El monolito no falla: cambia el escenario
En el trabajo, la evolución hacia microservicios no aparece porque sí. Sucede por un cambio en el negocio: el sistema deja de ser para una clínica y pasa a pensarse como un SaaS para múltiples clínicas.
Ese cambio modifica las necesidades. Ya no hay una sola organización usando el sistema, sino múltiples clínicas con datos que deben mantenerse aislados. Aparecen nuevos dominios como tenants, suscripciones, planes, límites de uso y facturación. También cambia la carga del sistema: las reservas de turnos pueden distribuirse durante el día, pero los recordatorios de WhatsApp pueden concentrarse todos en una misma franja horaria.
En ese punto, la arquitectura en capas empieza a mostrar límites. No porque esté mal diseñada, sino porque el problema creció. Si el módulo de notificaciones tiene un pico de uso, no se puede escalar solo ese módulo. Si la API de Meta responde lento, puede afectar operaciones que no deberían depender de WhatsApp, como reservar un turno.
Esa fue una de las frases que más nos ayudó a razonar la arquitectura:
¿Por qué debería fallar una reserva de turno porque WhatsApp está lento?
A partir de esa pregunta, la separación en servicios empieza a tener sentido. Appointment, Notification, Medical Record, Identity, Tenant, Billing y Audit tienen responsabilidades distintas, ritmos de cambio distintos y necesidades de escalabilidad distintas.
Los eventos me enseñaron a separar hechos de efectos secundarios
Uno de los desafíos arquitectónicos más interesantes fue pasar de una comunicación síncrona entre servicios a una arquitectura orientada a eventos.
En un modelo completamente síncrono, reservar un turno puede implicar varias llamadas HTTP encadenadas: validar datos, consultar paciente, revisar configuración del tenant, enviar notificación y registrar auditoría. El problema es que todos esos servicios deben estar disponibles al mismo tiempo. Si uno falla, puede degradar toda la operación.
Con eventos, el flujo se piensa de otra forma. La reserva del turno necesita ser rápida y transaccional: validar disponibilidad y guardar el turno. Eso es el hecho de negocio principal. Luego, otros procesos pueden reaccionar a ese hecho: enviar un WhatsApp, registrar auditoría o actualizar una proyección.
Para garantizar que el evento no se pierda, incorporamos el patrón Outbox. La idea es guardar el turno y el evento en la misma transacción. Después, un proceso publica ese evento al broker. Así, aunque haya una falla entre la base de datos y la cola de mensajes, el sistema no pierde el hecho ocurrido.
El dominio limita los patrones
Otro aprendizaje fuerte fue que los patrones arquitectónicos no se deben aplicar de forma automática. Hay que validarlos con el dominio.
Por ejemplo, la consistencia eventual es muy útil para notificaciones, auditoría o tareas secundarias. Pero en una historia clínica no se puede aceptar que un dato médico sea “eventualmente consistente”. Una evolución, diagnóstico o indicación médica debe guardarse con consistencia fuerte, en una transacción confiable.
Lo mismo ocurre con el caché. Redis puede ser una buena herramienta para mejorar la disponibilidad de turnos, guardar tokens _revocados o _cachear configuraciones de una clínica. Pero no debería usarse para contenido clínico sensible. En un sistema médico, cada acceso a una historia clínica debe quedar auditado. Si una lectura se resuelve desde caché sin registrar adecuadamente el acceso, se rompe la trazabilidad.
Este fue uno de los puntos donde más noté el paso de “programar” a “diseñar”. Como programador, uno puede pensar: “uso caché porque mejora el rendimiento”. Como diseñador, la pregunta cambia: “¿qué consecuencias tiene cachear este dato en este dominio específico?”.
En sistemas de salud, la ley y el dominio no son detalles externos: son parte de la arquitectura.
DevOps no es el final, es parte del diseño
Antes de este trabajo, pensaba en DevOps como algo posterior: primero se desarrolla la aplicación y después se ve cómo desplegarla. Pero al diseñar una arquitectura completa, quedó claro que forma parte del diseño desde el principio.
Si se elige una arquitectura de microservicios con eventos, también hay que aceptar lo que viene con ella: observabilidad, trazabilidad distribuida, alertas, manejo de errores, reintentos, Dead Letter Queues, health checks, escalabilidad y pipelines confiables.
Una arquitectura que no se puede desplegar, monitorear ni mantener no es una arquitectura completa.
Por eso incorporamos ambientes como desarrollo, QA, UAT y producción; pipelines CI/CD; migraciones controladas; infraestructura como código con Terraform; y estrategias de despliegue que permitan reducir riesgos.
También entendimos que el costo es parte del diseño. No alcanza con decir “lo desplegamos en AWS con Kubernetes”. Hay que estimar cuánto cuesta, qué componentes son realmente necesarios y qué alternativas existen.
En nuestro análisis, Kubernetes aparece como estado objetivo por portabilidad y escalabilidad, pero también reconocemos que para un SaaS inicial una alternativa como Fargate puede ser más simple y económica. Ese reconocimiento me pareció importante: diseñar bien también implica aceptar cuándo una solución está sobredimensionada.
La IA como asistencia, no como reemplazo
La última etapa del trabajo incorporaba inteligencia artificial. Pero el aprendizaje principal fue entender que es una capacidad que también necesita arquitectura, límites y control humano.
En un sistema clínico, la IA no puede decidir ni escribir automáticamente en una historia clínica. Puede asistir: generar borradores, resumir antecedentes, ayudar a clasificar motivos de consulta o sugerir respuestas administrativas. Pero siempre debe existir validación humana.
También analizamos una posible arquitectura RAG, usando información interna y pgvector. Ahí apareció otro desafío: El sistema debe respetar permisos por rol y relación asistencial. Si un usuario no puede ver cierta información en el sistema, esa información tampoco debería entrar al contexto del modelo.
Esto me ayudó a entender que incorporar IA no elimina los problemas clásicos de arquitectura. Al contrario, los hace más importantes: permisos, auditoría, trazabilidad, minimización de datos y responsabilidad profesional.
En qué escenarios aplicaría esta arquitectura
La arquitectura final que diseñamos tiene sentido en productos que empiezan simples, pero tienen potencial de convertirse en plataforma.
Por ejemplo, sistemas de gestión para clínicas, consultorios, estudios profesionales, logística, educación o servicios B2B donde primero se valida con un cliente y después se escala a múltiples organizaciones.
También aplica en dominios donde existe un núcleo transaccional claro y varios efectos secundarios diferibles. En nuestro caso, el núcleo es reservar un turno o registrar una historia clínica. Los efectos secundarios son enviar notificaciones, auditar, actualizar reportes o disparar procesos posteriores.
No aplicaría esta arquitectura completa para cualquier proyecto. Si el producto no validó usuarios, no tiene carga real, no tiene múltiples clientes ni requiere escalabilidad independiente, empezar con microservicios probablemente sería una mala decisión.
En esos casos, una arquitectura en capas bien modular puede ser más que suficiente.
Conclusión: aprender a justificar decisiones
La mayor diferencia entre programar y diseñar está en la justificación.
Programar responde a la pregunta:
¿Cómo hago que esto funcione?
Diseñar agrega otras preguntas:
¿Por qué esta solución y no otra?
¿Qué costo tiene?
¿Qué riesgo reduce?
¿Qué complejidad agrega?
¿Se justifica en el momento del negocio actual?
Ese fue el mayor aprendizaje de la materia. No se trató solamente de elegir el stack con tecnologías como .NET, React, PostgreSQL, RabbitMQ, AWS o Terraform. Se trató de entender cuándo cada decisión tenía sentido.
En definitiva, el trabajo de esta asignatura me enseñó que desarrollar aplicaciones web va más allá de construir pantallas y endpoints. Es necesario aprender a tomar decisiones técnicas justificadas, entendiendo que cada patrón, tecnología e infraestructura tiene sentido únicamente cuando responde a un problema concreto.
