⏱️ Tiempo de lectura: 7 minutos

Microservicios vs Monolito: cuándo cada uno gana

Hay una conversación que se repite en casi todos los equipos. Alguien propone migrar a microservicios, otro dice que el monolito está bien, y en diez minutos ya nadie habla de la solución real. Están hablando de arquitectura como si fuera un concurso de popularidad.

Yo lo he vivido. Llegué a un proyecto donde el CTO quería microservicios porque "así lo hace Netflix". El equipo tenía cuatro personas. El tráfico era de doscientas peticiones diarias. Terminamos con ocho servicios, tres colas de mensajes y un Kubernetes que nadie sabía operar bien. Seis meses después, volvimos a un monolito. Nadie lo admitió en el retro, pero todos lo sabíamos.

El punto no es cuál arquitectura es mejor. El punto es que la mayoría de los equipos elige la arquitectura que suena más impresionante, no la que resuelve sus problemas reales.

El monolito no es un fracaso arquitectónico

Hay una narrativa instalada en la industria que dice que los monolitos son código legacy, deuda técnica acumulada, algo que eventualmente "hay que arreglar". Eso es una simplificación peligrosa.

Un monolito bien estructurado —con módulos claros, separación de responsabilidades y buenos límites internos— es perfectamente capaz de escalar hasta niveles que la mayoría de las empresas jamás alcanzará. Shopify, Stack Overflow y Basecamp llevan años demostrándolo. No son excepciones raras. Son ejemplos de equipos que decidieron no agregar complejidad innecesaria.

La trampa es confundir monolito con big ball of mud. Un monolito no es sinónimo de código acoplado sin estructura. Puedes tener un monolito modular, con dominios bien definidos, que sea más mantenible que un sistema de veinte microservicios donde nadie sabe qué llama a qué.

El costo que nadie pone en la pizarra

Cuando alguien propone microservicios, el slide de presentación siempre muestra los beneficios: escalabilidad independiente, deploys separados, equipos autónomos. Lo que rara vez aparece es la columna de costos.

Con microservicios, de pronto tienes que resolver problemas que antes no existían: consistencia eventual, transacciones distribuidas, tracing entre servicios, latencia de red entre llamadas internas, gestión de secretos por servicio, estrategias de versionado de APIs. Cada uno de esos problemas tiene solución, claro. Pero cada solución agrega complejidad operacional.

En mi experiencia, el 80% de los proyectos que conozco no necesitan esa complejidad. Necesitan un monolito limpio y bien testeado.

Cuándo los microservicios sí tienen sentido

Dicho esto, hay escenarios donde la distribución no es un capricho sino una necesidad real.

El caso más claro es cuando tienes dominios con requisitos de escala radicalmente distintos. Si tu módulo de procesamiento de video necesita cien veces más recursos que tu módulo de autenticación, tiene sentido separarlos. Escalar todo junto porque una parte lo necesita es desperdiciar plata.

Otro caso válido es cuando tienes equipos grandes trabajando sobre la misma base de código y el acoplamiento empieza a generar cuellos de botella reales: merges conflictivos, builds lentos, deploys que bloquean a otros equipos. Ahí los microservicios no son una moda, son una herramienta de organización humana tanto como técnica.

Y hay un tercer caso que se menciona poco: cuando partes de tu sistema tienen ciclos de vida completamente distintos. Un motor de reglas que cambia cada semana no debería estar atado al mismo ciclo de deploy que un módulo de facturación que lleva un año estable.

El patrón que más me ha funcionado: el monolito modular como punto de partida

Algo que aprendí a las malas es que extraer microservicios es mucho más fácil cuando ya tienes los límites claros en un monolito. Si no sabes dónde termina un dominio y empieza otro dentro de tu propio código, ¿cómo vas a saberlo cuando lo conviertas en un servicio separado?

El flujo que me ha funcionado es este: empieza con un monolito bien modularizado. Define límites de dominio claros desde el principio. Cuando algún módulo tenga razones concretas para separarse —escala diferente, equipo diferente, ciclo de vida diferente— entonces extraes. No antes.

Esto no es una idea nueva. Martin Fowler lo llama "monolito modular" y Sam Newman habla de ello en Building Microservices. Pero sigue siendo ignorado porque no suena tan emocionante en una presentación.

La pregunta que deberías hacerte antes de decidir

Antes de elegir arquitectura, hay una pregunta que vale más que todas las comparativas técnicas: ¿cuál es el mayor riesgo que necesito mitigar ahora mismo?

Si el riesgo es velocidad de desarrollo y el equipo es pequeño, un monolito minimiza la fricción. Si el riesgo es escala de un componente específico, extrae ese componente. Si el riesgo es acoplamiento entre equipos, los microservicios tienen sentido como herramienta organizacional.

La arquitectura no es un fin en sí misma. Es una respuesta a riesgos concretos. Cuando la tratas como un objetivo en lugar de una herramienta, terminas optimizando para el CV de alguien, no para el producto.

Ojo que esto no significa que la decisión sea para siempre. Las arquitecturas evolucionan. Lo que importa es que la decisión de hoy tenga sentido para el contexto de hoy, y que el código esté estructurado de forma que puedas cambiar de dirección sin reescribir todo desde cero.

Señales de que tu arquitectura actual está fallando

Más allá de la discusión teórica, hay señales concretas que indican que algo no está funcionando:

Si tienes microservicios y cada feature requiere cambios coordinados en cinco servicios distintos, tus límites de dominio están mal definidos. No es un problema de arquitectura distribuida, es un problema de diseño.

Si tienes un monolito y los builds tardan veinte minutos porque todo está acoplado a todo, el problema no es que sea monolito, es que no tiene estructura interna.

En ambos casos, la solución empieza por entender los dominios del negocio, no por cambiar el tipo de arquitectura.

Antes de irte

Si estás en medio de esa discusión en tu equipo —microservicios vs monolito— y sientes que nadie está hablando de lo mismo, es probable que tengas razón. Esas conversaciones suelen mezclarse con egos, con lo que alguien leyó la semana pasada, con miedo a parecer que no estás al día. Es agotador, y entiendo que a veces da ganas de simplemente ceder para que la reunión termine.

La arquitectura que mejor funciona no es la más sofisticada, sino la que tu equipo puede operar, entender y cambiar sin que nadie se quiera ir a casa antes de las cinco.