Durante mucho tiempo pensé que ser mejor desarrollador era escribir mejor código. Después con el equipo nos pusimos a diseñar un MVP para una clínica que evoluciona en un futuro a un SaaS multi tenant para un cliente y en el futuro poder escalar para muchos más, y entendí que el código era la parte fácil. Lo difícil era decidir qué no construir todavía.
La decisión más importante fue la más aburrida
Cuando arranqué el diseño la tentación era obvia: microservicios, eventos y Kubernetes. Es lo que se lee, es lo que se suma en el CV. No digo que microservicios esté mal. El tema es que tiene un costo que solo tiene sentido pagar a partir de cierto tamaño, y al principio de un proyecto no estás ahí. Si separás todo en servicios cada uno necesita su propio pipeline, hay que versionar cómo se hablan entre ellos, y cuando algo falla tenés que rastrear el error pasando por varios procesos en vez de uno. Con un equipo de tres personas y pocos usuarios eso es trabajo de más sin ningún beneficio real todavía. Si el equipo crece y cada parte del sistema empieza a cambiar a un ritmo distinto ahí sí empieza a valer la pena, pero hacerlo antes es resolver un problema que todavía no existe. Elegí una arquitectura en capas con .NET 8 y PostgreSQL corriendo en una plataforma de USD 20/30 por mes.
Fue decisión, no resignación. Un equipo de 3 personas que adopta microservicios paga contratos entre servicios, versionado, debugging distribuido, observabilidad seria y una factura de cloud de cientos de dólares, para servir a una clínica con treinta usuarios concurrentes. Todo costo, ningún beneficio, y es lo que producís cuando partís un sistema antes de entender dónde están sus costuras reales.
Lo que sí hice fue tener criterio en las decisiones baratas de tomar y carísimas de revertir: una columna TenantId en todas las tablas cuando existía un solo tenant, Docker desde el primer commit, una interfaz delante del proveedor de WhatsApp. Ninguna me costó más de una tarde. Al escalar después, eso se convertiría de una migración dolorosa en un cambio de configuración. La del TenantId en particular la añadimos por planificación, para poder recibir más de un cliente.
La arquitectura en capas queda chica para multi tenant, pero no porque fuera mala
El sistema, al evolucionar a SaaS, empezaría a sufrir. Los recordatorios de WhatsApp, si se llegaran a disparar todos en la misma franja horaria, no podrían escalar solo ese módulo. O peor: una degradación de la API de Meta podía arrastrar la reserva de turnos, y no hay forma de explicarle a una recepcionista que no puede dar un turno porque WhatsApp está lento.
Esa frase fue mi argumento para los eventos. La reserva de un turno tiene una sola operación que debe ser síncrona y transaccional: validar disponibilidad y escribir el turno. Todo lo demás, el mensaje, la auditoría, son efectos que pueden ocurrir dos segundos después, con garantía de que ocurren (patrón Outbox) pero sin bloquear a nadie. Esto sigue corriendo todo en el mismo deploy, la cola no es otro servicio, es solo una forma de organizar el trabajo dentro del mismo sistema. Cuando Meta falla, los mensajes esperan en una cola y reintentan con backoff; si agotan los reintentos van a una dead letter queue con alerta. El turno, mientras tanto, ya existe. El hecho de negocio nunca debió depender de su notificación.
El dominio te corrige los patrones que traías de memoria
La lección que menos esperaba era que los patrones no se aplican, se negocian con el dominio. Consistencia eventual es una herramienta hermosa que tuve que sacar para la historia clínica, porque un diagnóstico eventualmente consistente es un riesgo legal, no una optimización. Lo mismo con el caché. Redis para disponibilidad de turnos, sí. Para contenido clínico, no, porque cada lectura de una historia clínica tiene que quedar auditada, y un cache hit silencioso rompe esa trazabilidad que la ley argentina exige.
Diseñar para salud me obligó a leer la 25.326 y la 26.529, y ahí entendí que los requisitos legales son requisitos arquitectónicos disfrazados. "La historia clínica es inviolable" se traduce en código en append only, soft delete y un servicio de auditoría de primera clase.
La parte de infraestructura me llevó más tiempo del que esperaba
Acá es donde más me equivoqué al principio. Mi primer borrador de la arquitectura de eventos no incluía presupuesto para tracing distribuido ni para alertas sobre las colas, y eso casi me lleva a repetir el mismo error que estaba criticando: diseñar algo elegante en el diagrama e inoperable en producción. Una arquitectura que no podés operar no es una arquitectura, es un dibujo.
Terminé presupuestando pipelines con migraciones expand/contract, para poder hacer rollback del código sin hacer rollback de la base, y armando una tabla de costos que incluía el NAT Gateway, que en casi todos los presupuestos que vi antes (incluido el mío en el primer intento) aparece como una línea olvidada. Esa tabla me llevó a la conclusión más incómoda del proyecto: para el tamaño real de este SaaS, Fargate salía más barato y más simple que Kubernetes.
Para no quedarme solo con la sensación me puse a armar números reales. Calculando todo: cluster, nodos, balanceador, NAT Gateway, un setup de Kubernetes (EKS) para este proyecto salía entre 545 y 615 dólares por mes. El mismo sistema en Fargate, sin tener que mantener un cluster, se quedaba entre 350 y 420. No es una diferencia menor, es bastante más de 150 dólares todos los meses solo por la decisión de infraestructura. Lo documenté igual, porque también es parte del trabajo poder decir "esto que estoy mostrando está sobredimensionado para hoy".
Toda esta arquitectura en capas con eventos por encima tiene un techo, y lo sé porque lo dejé planificado para cuando llegue: si esto en algún momento pasa de unas pocas clínicas a unas cuarenta, ya no alcanza con un solo sistema mandando todo a una cola. Ahí sí entran los microservicios de verdad, separados por dominio (turnos, identidad, historia clínica, cada uno con su base), con un API Gateway adelante. No es que los microservicios estuvieran mal desde el principio, es que recién a ese tamaño el costo de tenerlos separados se paga solo, porque cada parte empieza a tener su propia carga y su propio ritmo de cambio. Hasta entonces, partir el sistema es pagar por un problema que todavía no tengo.
Dónde aplicaría esto y dónde no
Esto lo aplicaría de nuevo en cualquier proyecto que arranca con un cliente real y la idea de convertirse en plataforma más adelante. No tiene que ser una clínica, puede ser un estudio jurídico llevando expedientes o una empresa de logística coordinando repartos. La idea de fondo es la misma: hay una operación principal que tiene que pasar sí o sí (el turno, el expediente, el envío) y un montón de cosas alrededor que pueden tardar un par de segundos sin que nadie se entere (mandar una notificación, guardar un log, avisarle a otro sistema). Separar esas dos cosas es lo que hace que la arquitectura tenga sentido.
Lo que no haría es este mismo trabajo si todavía no hay un cliente pagando. Ahí toda esta arquitectura es como diseñar la expansión de un local que todavía no abrió. Vi proyectos gastando semanas pensando en cómo van a escalar para veinte clientes que todavía no existen, mientras el primer cliente sigue esperando algo mucho más simple.
Y si el proyecto sí llega a crecer, tampoco haría el salto a microservicios de una. Iría por el mismo camino: capas primero, eventos cuando aparece el primer cliente externo que depende de algo como WhatsApp, y microservicios solo cuando el volumen y la cantidad de equipos lo piden de verdad. No es que cada etapa sea un premio por haber superado la anterior, es que cada una resuelve un problema que en la etapa anterior todavía no existía. Adelantarse a cualquiera de los tres pasos sale caro, atrasarse también. La parte difícil no es saber que los microservicios existen, es saber en qué momento del negocio recién empiezan a valer lo que cuestan.
