Microservicios: arquitectura, patrones y cómo implementarlos en Chile

Los microservicios son un estilo de arquitectura donde una aplicación se construye como un conjunto de servicios pequeños, autónomos y desplegables de forma independiente, cada uno responsable de una capacidad de negocio acotada y comunicándose por APIs o mensajería asíncrona. Conviene usarlos cuando una empresa enfrenta tres síntomas simultáneos: equipos múltiples bloqueándose en el mismo repositorio monolítico, partes del sistema con requerimientos de escalabilidad muy distintos (ej: catálogo vs checkout en un e-commerce) y un dominio de negocio complejo con bounded contexts claros. No conviene cuando el equipo es pequeño (<10 developers), el sistema todavía no encuentra product-market fit o no hay madurez en DevOps, observabilidad y testing automatizado. Empezar con microservicios sin esa base produce un "monolito distribuido": toda la complejidad de la red sin ninguno de los beneficios reales.

SOA (Service-Oriented Architecture) y microservicios comparten ADN —descomponer en servicios— pero difieren en granularidad, gobernanza y stack. SOA, en su versión clásica corporativa de los 2000s, se apoyaba en un Enterprise Service Bus (ESB) centralizado, protocolos pesados como SOAP/XML, gobernanza top-down y servicios grandes alineados a procesos de negocio completos. Microservicios son más pequeños (un servicio = una capacidad acotada), se comunican con protocolos livianos (HTTP/JSON, gRPC, eventos), evitan el ESB centralizado a favor de smart endpoints + dumb pipes, y cada equipo dueño de su servicio elige stack y release cadence. En la práctica chilena, muchas empresas grandes (banca, retail tradicional) todavía operan SOA legacy con buses Oracle/IBM y migran progresivamente a microservicios sobre Kubernetes y API gateways modernos.

Una migración seria de monolito a microservicios en Chile parte desde $25.000.000 CLP para un primer corte (Strangler Fig sobre 2–4 bounded contexts, API Gateway, observabilidad mínima, CI/CD), y puede ir entre $60.000.000 y $250.000.000 CLP para un programa completo de 12–24 meses que incluye plataforma interna (Kubernetes, service mesh, registry, secrets), descomposición de 8–20 servicios, contract testing, instrumentación distribuida y capacitación del equipo. El costo real no son las herramientas: es el rediseño del modelo de dominio, la coordinación entre equipos y el reescribir lógica que muchas veces está implícita en el monolito. Hay que sumar costo de operación post go-live (DevOps continuo, observabilidad, on-call), que en una empresa mediana es del orden de USD 4.000–12.000 mensuales en cloud + tooling. Si tu monolito todavía funciona y el problema es solo escalabilidad, primero evalúa si conviene escalar vertical/horizontal antes de partir.

No es obligatorio, aunque en la práctica termina siendo la opción más estándar. Microservicios pueden correr perfectamente en alternativas más simples: AWS ECS, Google Cloud Run, Azure Container Apps, Fly.io o incluso VMs con docker-compose si son pocos servicios. Kubernetes aporta valor cuando hay 8+ servicios, múltiples equipos desplegando en paralelo, necesidad de autoscaling fino por servicio, multi-tenancy o requerimientos avanzados de service mesh (mTLS, traffic shifting, canary). Para una empresa chilena partiendo con 3–6 microservicios, Cloud Run o ECS suelen ser más rentables y simples de operar que un cluster EKS/GKE. La regla práctica: si tu equipo de plataforma tiene menos de 2 personas dedicadas a infra, evita Kubernetes self-managed; usa un managed (EKS/GKE/AKS) o, mejor, una abstracción más alta como Cloud Run hasta que se justifique.

Strangler Fig es un patrón de migración acuñado por Martin Fowler: en lugar de reescribir el monolito de una vez (big-bang, alto riesgo), se va envolviendo y reemplazando funcionalidad pieza por pieza hasta que el monolito queda "estrangulado" y se puede eliminar. En la práctica funciona así: se pone un router/API Gateway delante del monolito, se identifica una capacidad acotada (ej: gestión de usuarios), se construye el microservicio nuevo, se redirige el tráfico de esa capacidad al nuevo servicio dejando todo lo demás en el monolito, y se repite. Importa porque permite valor entregado continuo, rollback simple si algo falla, y evita el clásico "proyecto de reescritura de 2 años que nunca termina". En Chile, casi todas las migraciones exitosas de monolito a microservicios que hemos visto usaron alguna variante de Strangler Fig, y casi todos los fracasos intentaron un big-bang.

En un monolito, una transacción ACID dentro de la base de datos resuelve consistencia entre módulos. En microservicios cada servicio tiene su propia base de datos, así que las transacciones distribuidas tradicionales (2PC) son caras y frágiles. El patrón estándar es Saga: la transacción se modela como una secuencia de pasos locales (cada microservicio ejecuta su parte y publica un evento), con acciones compensatorias para revertir si algún paso falla. Hay dos variantes: orquestada (un servicio coordinador dirige la saga) y coreografiada (los servicios reaccionan a eventos sin coordinador). Junto con Saga, se acepta eventual consistency: el sistema puede estar momentáneamente inconsistente y converge a un estado correcto. Esto requiere diseñar el negocio para tolerar esa ventana (ej: "tu pedido fue recibido, te confirmamos en segundos") y herramientas como outbox pattern, idempotencia y dead letter queues. No es opcional: si el equipo no entiende Saga y eventual consistency, los microservicios fallarán en producción.

En la mayoría de los casos, no. Una PyME chilena con 1–3 developers y un solo producto se beneficia más de un monolito modular bien diseñado (módulos separados, base de datos única, deploy único) que de microservicios. Microservicios introducen complejidad operacional —service discovery, observabilidad distribuida, transacciones distribuidas, contract testing, networking— que cuesta caro si no hay equipo dedicado a plataforma. La excepción son PyMEs SaaS con product-market fit claro, crecimiento de tráfico sostenido y planes de escalar equipo más allá de 8–10 developers en los próximos 12–18 meses: ahí sí vale la pena diseñar desde temprano para descomponer cuando duela. La recomendación práctica: empieza con monolito modular bien hecho, identifica los bounded contexts del dominio (DDD), y extrae microservicios solo cuando el dolor de seguir en el monolito sea mayor que el costo operacional de tener un servicio aparte.

Una migración seria de monolito a microservicios para una empresa chilena mediana toma entre 12 y 24 meses si se hace con Strangler Fig y entregas continuas. El primer corte (3–6 meses) suele incluir: diagnóstico de bounded contexts, definición de la plataforma base (Kubernetes o equivalente, API Gateway, observabilidad, CI/CD), extracción del primer 1–3 servicios y validación en producción con tráfico real. Los siguientes 6–18 meses se dedican a extraer más servicios en olas, refactorizar el monolito, instrumentar contract testing y entrenar al equipo en patrones (Saga, CQRS, event-driven). Las migraciones que se prometen en 3 meses casi siempre terminan en monolito distribuido. Las que se prometen en 5 años nunca terminan. El sweet spot es 12–18 meses con un equipo dedicado de 4–8 personas y respaldo ejecutivo claro.