Definición
Un monolito es una aplicación construida y desplegada como una sola pieza: todo el código vive junto, se compila junto y se publica junto.
La palabra suele usarse con desdén, y conviene deshacer ese prejuicio: para la inmensa mayoría de proyectos, el monolito es la decisión correcta. Los microservicios resuelven problemas que aparecen a una escala organizativa que casi ningún proyecto alcanza, y a cambio introducen complejidad desde el primer día.
Lo que hace bien
Es simple de entender. Todo el código está en un sitio. Puedes seguir una operación de principio a fin sin saltar entre sistemas.
Es simple de desplegar. Un artefacto, un despliegue.
Es simple de depurar. Un error deja una traza completa. En un sistema distribuido, esa traza está repartida entre cinco servicios y hay que reconstruirla.
Las transacciones son triviales. Una sola base de datos, una transacción, y o se hace todo o no se hace nada. Conseguir esa garantía repartida entre servicios es de lo más difícil que hay.
Refactorizar es barato. Cambiar la firma de una función y sus llamadas es una operación mecánica. Cambiar el contrato de una API entre servicios implica coordinar despliegues.
Sus límites reales
Son reales, y aparecen más tarde de lo que se suele decir:
Un despliegue afecta a todo. Un cambio pequeño obliga a publicar la aplicación entera.
Un fallo grave puede tumbarlo todo, sin fronteras que lo contengan.
Escala en bloque. Si solo una parte necesita más recursos, hay que replicar el conjunto. En la práctica es un problema menor de lo que parece.
Cuesta que trabajen muchos equipos a la vez sobre el mismo código. Este es el límite de verdad, y es organizativo, no técnico.
Ejemplo práctico
Un sistema de gestión de empresa —clientes, pedidos, almacén, facturación, informes— es el caso donde el monolito gana con claridad.
Lo que aprendí: la razón es que todo está relacionado con todo. Un pedido toca cliente, stock, precios, documentos y contabilidad, y a menudo en la misma operación. Partir eso en servicios convierte una transacción de base de datos en una coreografía distribuida con estados intermedios, compensaciones y fallos parciales. El coste de esa decisión es enorme y el beneficio, con un equipo pequeño, es nulo.
El segundo aprendizaje, y es el que de verdad importa: el problema nunca fue el monolito, fue el monolito desordenado. Un código donde todo llama a todo, sin fronteras internas, se vuelve intocable — y entonces se culpa a la arquitectura de lo que es falta de disciplina.
La alternativa sensata es el monolito modular: una sola aplicación, un solo despliegue, y por dentro módulos con responsabilidades claras que se comunican por interfaces definidas en vez de meter mano directamente en las tablas del vecino.
Eso da casi todas las ventajas que se le atribuyen a los microservicios —límites claros, código comprensible, equipos que no se pisan— sin la complejidad de operar diez sistemas. Y deja preparada la puerta: si algún día un módulo tiene que salir, ya está delimitado.
Y una advertencia sobre la moda: dividir «porque es lo moderno» es el camino más rápido a lo peor de los dos mundos — un sistema distribuido con las dependencias de un monolito, donde nada se puede desplegar por separado y todo puede fallar por separado.
Errores comunes
- Tratar «monolito» como sinónimo de mal hecho.
- Empezar con microservicios en un equipo pequeño.
- Monolito sin módulos, donde todo accede a todo.
- Dividir por moda y no por un problema concreto.
- Módulos que comparten tablas directamente, que es tener el nombre sin la frontera.
- Confundir el problema organizativo con uno técnico.
- Dejar que el desorden crezca hasta que dividir parezca la única salida. Ver deuda técnica.
Cuándo elegirlo
Por defecto, y especialmente con equipos de menos de diez personas, dominios muy interrelacionados o un producto que aún está cambiando de forma.
La pregunta que decide dividir: ¿qué problema concreto tengo hoy que esto resuelva? Si la respuesta es «ninguno, pero es lo que se lleva», la respuesta es quedarse — y dedicar el esfuerzo a ordenar los módulos por dentro.
