Blog
Monolito o microservicios: cuándo sí conviene separar.
En resumen. Los microservicios se justifican cuando hay equipos que necesitan desplegar de forma independiente, partes del sistema con necesidades de escala o de disponibilidad muy distintas, y límites de dominio que ya son estables. Si no se cumplen esas condiciones, un monolito bien modularizado suele ser más rápido de construir, más fácil de operar y más sencillo de separar después, cuando de verdad haga falta.
Señales de que separar tiene sentido
- Varios equipos trabajan sobre el mismo código y se bloquean entre sí para desplegar.
- Una parte del sistema recibe mucha más carga que el resto y hay que escalarla sola.
- Un componente tiene requisitos de disponibilidad o de seguridad distintos a los demás.
- Hay partes que cambian cada semana y partes que no se tocan en meses.
- Los límites del dominio están claros y llevan tiempo sin moverse.
Señales de que todavía no
- El equipo completo cabe en una mesa.
- El producto todavía está descubriendo qué es, y los límites entre módulos cambian cada mes.
- Casi todas las operaciones importantes tocan datos de varios módulos a la vez.
- No hay integración continua, monitoreo ni trazas: sin eso, un sistema distribuido es imposible de depurar.
- La motivación principal es que «así lo hacen las empresas grandes».
La complejidad que se añade
Separar un sistema no elimina complejidad: la mueve del código a la red. Cada llamada que antes era una función ahora puede fallar, tardar o llegar dos veces. Aparecen problemas que en un monolito no existían:
- Consistencia: una operación que abarca varios servicios ya no cabe en una transacción.
- Contratos: cada API se versiona y cualquier cambio exige coordinar a quienes la consumen.
- Operación: más despliegues, más configuraciones, más infraestructura que vigilar.
- Depuración: seguir un error exige trazas distribuidas y registros correlacionados.
- Pruebas: validar un flujo completo requiere levantar varias piezas a la vez.
El punto intermedio: un monolito modular
Entre un monolito desordenado y una red de microservicios hay una opción que recomendamos con frecuencia: un solo sistema desplegable, dividido por dentro en módulos con límites estrictos. Cada módulo es dueño de sus datos y expone una interfaz clara a los demás, aunque todo se ejecute en el mismo proceso.
Así se obtiene la mayor parte del orden de los microservicios sin pagar su costo operativo. Y si un día un módulo necesita separarse, el trabajo ya está a medio hacer: sus límites existen y sus dependencias son visibles.
Si decides separar, cómo hacerlo
Separar de golpe casi nunca sale bien. El camino que seguimos es gradual:
- Pon observabilidad primero: métricas, registros y trazas antes de mover nada.
- Elige el primer servicio por el borde con menos acoplamiento, no por el más importante.
- Define el contrato de la API antes de escribir el servicio, y pruébalo.
- Dale al servicio sus propios datos; compartir la base de datos anula buena parte del beneficio.
- Redirige el tráfico poco a poco y mantén la versión anterior como respaldo mientras tanto.
- Repite solo si el primer servicio dejó la operación mejor que antes.
En resumen
La pregunta útil no es «¿monolito o microservicios?», sino «¿qué problema concreto resolvería separar esto, y es mayor que el costo de operarlo?». Si la respuesta no es clara, empieza con un monolito modular. Si ya tienes un sistema y dudas, una revisión de su arquitectura te dirá dónde están los límites naturales antes de invertir en moverlos.