Microservicios vs Monolito: la verdad sin el hype de las conferencias
Si pasas tiempo en conferencias de tecnología o leyendo blogs técnicos, llegarás a la conclusión de que todos usan microservicios y que el monolito es una reliquia del pasado.
No es cierto. Y creer esa narrativa ha llevado a muchos equipos a construir arquitecturas innecesariamente complejas que los frenan en lugar de ayudarlos.
Qué es un monolito (y por qué “monolito” no es un insulto)
Un monolito es una aplicación donde todo el código se despliega junto como una unidad. El backend, la lógica de negocio, el acceso a datos — todo en el mismo proceso.
Netflix, Amazon y Uber empezaron como monolitos. Shopify, Stack Overflow y Basecamp siguen siendo fundamentalmente monolíticos — y sirven a millones de usuarios.
Un monolito bien construido tiene ventajas reales:
- Simplicidad operativa: un solo proceso para monitorear, un solo deploy, logs centralizados
- Llamadas en proceso: sin latencia de red entre servicios, sin problemas de consistencia distribuida
- Transacciones simples: una transacción de base de datos puede abarcar cualquier operación del sistema
- Desarrollo más rápido al inicio: sin gestionar múltiples repositorios, contratos de API entre servicios o entornos de desarrollo complejos
Qué son los microservicios (y por qué tienen sentido en algunos contextos)
Los microservicios dividen la aplicación en servicios independientes, cada uno con su propio proceso, base de datos y ciclo de deploy.
Tienen sentido cuando:
-
Equipos grandes trabajan en el mismo producto: si tienes 50 desarrolladores, un monolito genera conflictos de merge, builds lentos y deploys que requieren coordinación. Los microservicios permiten que cada equipo tenga autonomía real.
-
Partes del sistema tienen requisitos de escala radicalmente diferentes: el servicio de notificaciones necesita escalar diferente al servicio de autenticación. En un monolito, escalar uno significa escalar todo.
-
Necesitas diferentes tecnologías para diferentes problemas: un servicio de machine learning en Python puede coexistir con un servicio de transacciones en Go y un servicio de frontend en Node.
El problema de adoptar microservicios demasiado pronto
Hemos visto startups de 3 personas con arquitecturas de 12 microservicios. El resultado invariablemente es el mismo: la mayor parte del tiempo del equipo se va en operaciones — gestión de contenedores, debugging de llamadas entre servicios, sincronización de datos distribuidos — y queda poco tiempo para construir el producto.
Los microservicios traen consigo:
- Complejidad de red: las llamadas entre servicios pueden fallar. Necesitas circuit breakers, retry logic, timeouts.
- Consistencia eventual: sin transacciones ACID entre servicios, los datos pueden estar temporalmente inconsistentes.
- Overhead operativo: cada servicio necesita su propio CI/CD, monitoreo, alertas, logging.
- El problema de las “two-phase commits”: coordinar operaciones que deben ser atómicas entre múltiples servicios es genuinamente difícil.
La arquitectura correcta para la mayoría de productos
Monolito modular: un solo repositorio y proceso de deploy, pero con el código organizado en módulos con límites claros. El módulo de pagos no importa directamente del módulo de usuarios — se comunican a través de interfaces bien definidas.
Esto te da:
- La simplicidad operativa del monolito
- La separación de responsabilidades que facilita la evolución del código
- La posibilidad de extraer un módulo como microservicio si alguna vez tiene sentido — sin reescribir todo
La regla que usamos
Empieza con un monolito. Si alguno de estos problemas se vuelve real (no hipotético):
- El tiempo de deploy supera los 20 minutos
- Un equipo específico no puede lanzar sin coordinar con otros
- Una parte del sistema necesita escalar 10x más que el resto
- Quieres usar tecnologías incompatibles para partes distintas
…entonces extrae ese servicio. Uno a la vez, con criterio.
La arquitectura correcta no es la más sofisticada — es la que permite a tu equipo moverse rápido con el tamaño que tiene hoy.
Comparación lado a lado
| Criterio | Monolito (modular) | Microservicios |
|---|---|---|
| Velocidad inicial | Alta | Baja (overhead de setup) |
| Simplicidad operativa | Un deploy, logs centralizados | Cada servicio con su CI/CD y monitoreo |
| Transacciones | ACID directas | Consistencia eventual, sagas |
| Autonomía de equipos | Limitada con equipos grandes | Alta |
| Escala granular por componente | No (escalas todo junto) | Sí |
| Costo de debugging | Bajo (un proceso) | Alto (llamadas distribuidas) |
| Equipo ideal | Pequeño a mediano | Grande, con DevOps dedicado |
El monolito distribuido: lo peor de ambos mundos
Existe un anti-patrón que conviene nombrar para evitarlo: el monolito distribuido. Ocurre cuando divides el sistema en microservicios pero quedan tan acoplados entre sí que no puedes desplegar uno sin desplegar los otros. Tienes toda la complejidad operativa de los microservicios (red, latencia, despliegues múltiples) sin ninguno de sus beneficios (autonomía, despliegue independiente).
Suele pasar cuando se separan servicios por capas técnicas (un servicio de “base de datos”, otro de “lógica”, otro de “API”) en lugar de por dominios de negocio. La división correcta sigue las fronteras del negocio: un servicio de pagos, uno de notificaciones, uno de usuarios — cada uno dueño de sus datos y desplegable por su cuenta. Si dos servicios siempre cambian juntos, probablemente deberían ser uno solo.
Cuándo los microservicios sí tienen sentido desde el inicio
Si estás construyendo infraestructura crítica que sabes que va a necesitar diferentes SLAs (Service Level Agreements) para diferentes componentes, y tienes el equipo para operarlos: adelante.
Si estás construyendo el MVP de un SaaS con 3 desarrolladores: no.
Preguntas frecuentes
¿Microservicios o monolito para un proyecto nuevo?
Para la mayoría de productos, un monolito bien construido es la mejor decisión. Empresas como Shopify, Stack Overflow y Basecamp sirven a millones de usuarios con arquitecturas fundamentalmente monolíticas. Los microservicios tienen sentido con equipos grandes, partes del sistema con necesidades de escala muy distintas o tecnologías incompatibles entre componentes — no por defecto.
¿Qué es un monolito modular?
Es la arquitectura que recomendamos para la mayoría de productos: un solo repositorio y proceso de deploy (la simplicidad operativa del monolito), pero con el código organizado en módulos de límites claros que se comunican por interfaces definidas. Te da separación de responsabilidades y la opción de extraer un módulo como microservicio en el futuro, sin la complejidad distribuida desde el día uno.
¿Por qué es un error adoptar microservicios demasiado pronto?
Porque traen complejidad de red (llamadas que fallan, circuit breakers, retries), consistencia eventual sin transacciones ACID entre servicios y overhead operativo (cada servicio necesita su CI/CD, monitoreo y alertas). Una startup de 3 personas con 12 microservicios gasta la mayor parte del tiempo en operaciones en lugar de construir el producto. La complejidad llega antes que el beneficio.
¿Cuándo conviene migrar de monolito a microservicios?
Cuando un problema concreto se vuelve real, no hipotético: el tiempo de deploy supera los 20 minutos, un equipo no puede lanzar sin coordinar con otros, una parte del sistema necesita escalar 10 veces más que el resto, o necesitas tecnologías incompatibles para componentes distintos. Entonces extraes ese servicio específico, uno a la vez, con criterio — no reescribes todo de golpe.
¿Los monolitos escalan?
Sí. Un monolito bien construido escala vertical y horizontalmente con read replicas, caché y balanceo de carga, y sirve a millones de usuarios en empresas reales. La escalabilidad rara vez es la razón correcta para elegir microservicios; lo es más la autonomía de equipos grandes y las necesidades de escala radicalmente distintas entre componentes.
Compartir artículo