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.

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.