Monolitos

Resumen

Un monolito es una aplicación donde toda la lógica —interfaz de usuario, lógica de negocio, acceso a datos— vive en un solo proceso y se despliega como una unidad. Es la arquitectura por defecto con la que empieza casi todo proyecto, y no es intrínsecamente mala: es simple de desarrollar, testear y desplegar mientras el sistema y el equipo son chicos.

El problema aparece con la escala. Cuando el código base crece, el acoplamiento entre módulos aumenta, los tiempos de build y deploy se alargan, y coordinar cambios entre equipos se vuelve costoso. Es ahí donde se considera partir el monolito —no antes—.

Alcance y supuestos

Este paquete cubre la arquitectura monolítica como concepto, su rol como punto de partida natural y los patrones de migración. Asume familiaridad con APIs y sistemas distribuidos.

Modelo mental

Un departamento en un edificio donde vivís vos solo. Al principio es cómodo: todo está cerca, no hay que coordinar con nadie. Cuando se suma tu pareja, dos hijos y un perro, el departamento queda chico. Pero mudarse a cinco monoambientes separados tampoco es la solución correcta para todas las familias.

Uso práctico

• ✅ Proyectos nuevos, equipos chicos, dominios que todavía están definiéndose.
• ❌ Equipos de 50 personas tocando el mismo código base, deploys de 40 minutos porque hay que testear todo.

Ejemplo trabajado: el monolito que escaló bien

Una startup con 5 developers construye su producto como monolito Rails. Durante 3 años crece a 50 developers y 2 millones de usuarios. El build tarda 25 minutos, los deploys son traumáticos, y un cambio en el módulo de facturación rompe las notificaciones. Ahí, y solo ahí, el equipo decide partir. El monolito no fue un error: fue la arquitectura correcta durante 3 años.

Evidencia

• El monolito es el punto de partida natural. La decisión de partir hacia microservicios debe basarse en evidencia de dolor —acoplamiento, velocidad de deploy, coordinación—, no en moda arquitectónica.