Cuándo elegir monolito en 2026 (y por qué casi siempre es la respuesta)

Cada pocos meses llega un cliente con la misma pregunta, formulada de formas distintas: "¿deberíamos separar esto en microservicios desde ya, para no tener que migrar después?". La respuesta casi siempre es no. No porque los microservicios sean una mala idea en abstracto, sino porque resuelven un problema que la mayoría de los proyectos todavía no tiene.

Vamos a ser concretos sobre qué problema resuelven, qué coste tiene adoptarlos antes de tiempo, y qué señales objetivas indican que ya conviene dividir.

El monolito no es una fase inmadura

Hay una narrativa instalada según la cual el monolito es lo que haces "antes" de hacer arquitectura de verdad, y los microservicios son la versión adulta del mismo sistema. Esa narrativa está al revés en la mayoría de los casos.

Un monolito bien modularizado —con límites internos claros entre dominios, interfaces explícitas entre módulos y una sola base de código desplegable como unidad— te da casi todo lo que la gente busca en microservicios: separación de responsabilidades, código que se puede razonar en piezas, equipos que pueden trabajar en paralelo sin pisarse. Te lo da sin pagar el coste operacional de tener N servicios desplegados, versionados y monitorizados por separado.

La confusión habitual es tratar "monolito" y "código desordenado" como sinónimos. No lo son. El desorden es un problema de disciplina de ingeniería, no de topología de despliegue. Un sistema distribuido mal diseñado tiene el mismo desorden, solo que ahora cruza la red.

Lo que los microservicios cuestan de verdad

Cuando alguien propone microservicios, casi siempre enumera los beneficios (escalado independiente, despliegues aislados, libertad tecnológica por servicio) y se salta la lista de costes, que es igual de larga:

Complejidad operacional. Cada servicio nuevo es una unidad más que hay que desplegar, versionar, monitorizar, alertar y mantener con su propio pipeline de CI/CD. Con tres servicios eso es manejable. Con quince, la infraestructura para operarlos empieza a pesar más que el negocio que soportan.

Latencia de red donde antes había una llamada de función. Una llamada dentro de un mismo proceso es prácticamente gratis. La misma llamada convertida en una petición HTTP o gRPC entre servicios añade serialización, viaje de red, y un nuevo punto de fallo que no existía. Multiplica eso por cada frontera que cruzaste al dividir el sistema y el rendimiento agregado puede caer aunque cada servicio individual esté bien escrito.

Depuración distribuida. Cuando un bug vive en un solo proceso, un debugger y un stack trace lo encuentran. Cuando la petición cruza cuatro servicios, necesitas trazas distribuidas, correlación de logs entre sistemas, y reconstruir mentalmente un flujo que antes veías de corrido en una sola pila de llamadas. Esto no es un detalle: cambia cuánto tarda el equipo en resolver un incidente en producción, que es exactamente el momento en que menos tiempo tienes.

Coste cognitivo. Cada servicio adicional es otro repositorio, otro esquema de base de datos, otro contrato de API que mantener en sincronía, otra decisión sobre cómo versionar cambios sin romper a los consumidores. Ese coste no lo paga la arquitectura: lo paga el equipo, en cada code review, en cada onboarding, en cada incidente a las tres de la madrugada.

Nada de esto es teórico ni específico de una tecnología. Es la consecuencia directa de mover una frontera que antes estaba en memoria a una frontera que ahora cruza la red.

Cinco indicadores objetivos de cuándo sí conviene dividir

La pregunta útil no es "¿microservicios sí o no?" en abstracto, sino "¿qué problema concreto tengo que un monolito modular no resuelve?". Estos son los indicadores que consideramos razones reales, no intuiciones:

1. Escalado heterogéneo real. Un componente del sistema recibe órdenes de magnitud más carga que el resto, y escalar todo el monolito para atender a ese componente significa pagar por capacidad que el resto no necesita. Si el pico de tráfico de un módulo de notificaciones te obliga a escalar horizontalmente todo el backend, ahí hay un caso legítimo para separarlo.

2. Equipos que necesitan desplegar de forma independiente, y ya chocan por ello. No "podríamos tener equipos separados algún día", sino que ya existen dos o más equipos trabajando sobre el mismo monolito y sus despliegues se bloquean mutuamente con regularidad. Si un cambio de un equipo obliga a coordinar ventana de despliegue con otro equipo cada semana, la fricción es real y medible.

3. Requisitos de aislamiento que el proceso no puede dar. Aislamiento de fallos (que la caída de un componente no tumbe el resto), de cumplimiento normativo, o de seguridad, donde compartir proceso y memoria con otro módulo es, en sí mismo, el problema que hay que resolver.

4. Ciclos de vida de release genuinamente distintos. Un módulo cambia varias veces al día y otro casi nunca se toca. Desplegar el monolito completo por cada cambio menor en el módulo activo empieza a ser un coste que un servicio separado evitaría.

5. Volumen que ya rompió el monolito, medido, no proyectado. No "en dos años vamos a tener mucho tráfico", sino que hoy, con datos reales de producción, el monolito no sostiene la carga y el cuello de botella está identificado en un componente concreto.

Si ninguno de estos cinco aplica todavía, dividir el sistema no resuelve un problema que tengas: crea los cinco costes de la sección anterior a cambio de una flexibilidad que no vas a usar.

Lo que sí recomendamos desde el día uno

La alternativa a "monolito desordenado" no es "microservicios prematuros". Es un monolito modular: módulos con fronteras internas explícitas, comunicación entre ellos a través de interfaces bien definidas (no acceso directo a las tablas del módulo vecino), y equipos de dominio claros aunque compartan el mismo proceso de despliegue.

Esa disciplina hace dos cosas a la vez. Primero, te da la mayoría de los beneficios organizativos que la gente busca en microservicios sin pagar el coste de red y de operación. Segundo, y esto es lo que casi nadie menciona, es la que hace que el día que sí aparezca uno de los cinco indicadores, la extracción de un módulo a servicio independiente sea un cambio localizado y no una reescritura completa. Los límites ya existen en el código; solo hay que moverlos a la red.

Empezar con microservicios sin esas fronteras internas claras produce el peor de los dos mundos: pagas el coste operacional de un sistema distribuido, pero como los límites entre servicios se dibujaron antes de entender el dominio, terminas con acoplamiento fuerte entre servicios que deberían ser independientes. Eso es más difícil de arreglar que un monolito desordenado, porque ahora la refactorización cruza fronteras de red y de equipo.

La pregunta que le hacemos a cada cliente que llega con "queremos microservicios desde el inicio" no es si la arquitectura es válida en abstracto. Es cuál de los cinco indicadores ya tienen, medido. La mayoría de las veces la respuesta es ninguno todavía, y la recomendación que sale de ahí es construir el monolito modular, dejar las fronteras claras, y dividir cuando el problema real aparezca y no antes.