Cuándo dividir un proyecto en microservicios y cuándo no

La decisión de si construir una aplicación como un monolito o dividirla en microservicios es una de las más importantes en la arquitectura de software. No hay una respuesta única y la elección incorrecta puede paralizar un proyecto o disparar los costes de mantenimiento. Mi regla es que siempre se empieza con un monolito hasta que haya una razón de peso para no hacerlo.

Este no es un debate filosófico. Es una cuestión pragmática que tiene consecuencias directas en la velocidad de desarrollo, el coste de infraestructura y la capacidad de tu equipo para innovar. Una arquitectura de software bien elegida es una herramienta más para resolver problemas de negocio, no un fin en sí misma.

Monolito: la arquitectura por defecto para empezar

Un monolito es una aplicación donde todas las funcionalidades —interfaz de usuario, lógica de negocio, acceso a datos— están empaquetadas en una única unidad desplegable. Es el punto de partida natural para la mayoría de los proyectos, especialmente startups o productos en fase temprana. Permite una iteración rápida y un despliegue sencillo sin la complejidad añadida de la comunicación entre servicios.

Cuando un cliente me llega con una idea de producto, siempre propongo un monolito al principio. El foco está en validar el producto, conseguir los primeros usuarios y demostrar el valor de negocio, no en optimizar la escalabilidad extrema que quizás nunca llegue a ser necesaria. Es el camino con menor fricción para llegar a producción.

Cuando un monolito te frena de verdad

Un sistema monolítico empieza a mostrar sus limitaciones cuando el equipo crece o el producto se complejiza de forma exponencial. Los despliegues se vuelven más arriesgados porque un pequeño cambio en una parte del código puede tener efectos secundarios inesperados en otra. La base de código se hace tan grande que los nuevos desarrolladores tardan semanas en entender su funcionamiento y las dependencias internas.

Otro síntoma es la dificultad para escalar partes específicas de la aplicación. Si solo el módulo de procesamiento de pedidos necesita una alta concurrencia, pero el resto del sistema no, esta arquitectura te obliga a escalar toda la aplicación —desperdiciando recursos—. La diferencia entre un monolito funcional y uno que te frena no es su tamaño, sino la velocidad de desarrollo y la frecuencia de errores en producción. Si cada despliegue es un drama o un cambio en el módulo A requiere despliegues coordinados con el módulo B, el monolito ya no sirve.

Lo que los microservicios prometen y lo que no

Los microservicios son pequeñas aplicaciones independientes que se comunican entre sí a través de APIs bien definidas, cada una con su propia base de datos y ciclo de vida de despliegue. Prometen independencia, escalabilidad granular y la libertad de usar distintas tecnologías para diferentes partes del sistema. Esto significa que un equipo puede elegir Python para un servicio de IA y Go para otro de alto rendimiento, sin afectar al resto.

Lo que no prometen es simplicidad. La independencia de los equipos y la flexibilidad tecnológica tienen un precio importante en complejidad operativa. No es una bala de plata que resuelve todos los problemas de un monolito, sino que introduce un conjunto diferente de desafíos que requieren un equipo con experiencia en sistemas distribuidos.

El coste real de los microservicios: complejidad distribuida

El coste oculto de adoptar una arquitectura de microservicios no es solo el tiempo extra de desarrollo inicial. Es la complejidad inherente de un sistema distribuido que a menudo no se considera ni se presupuesta adecuadamente. Necesitas gestionar la comunicación entre servicios, la consistencia de los datos distribuidos, la monitorización holística, la observabilidad y la detección de errores en un entorno mucho más ruidoso y con más puntos de fallo.

Esto implica la necesidad de herramientas adicionales y personal especializado: un API Gateway, un sistema de mensajería robusto, un orquestador de contenedores como Kubernetes, y soluciones para el rastreo distribuido de peticiones. Cuando un cliente me pide microservicios, lo primero que pregunto es si su equipo está preparado para esta complejidad operativa y si tiene el presupuesto para mantenerla. Un problema común en entornos distribuidos es depurar por qué el código funciona en local y falla en producción — un desafío que se multiplica con microservicios debido a las innumerables interacciones de red.

Tradeoffs: lo que ganas y lo que complicas

Característica	Monolito	Microservicios
Desarrollo inicial	Rápido	Lento (por overhead)
Complejidad operativa	Baja	Alta (distribuida)
Escalabilidad	Monolítica (todo o nada)	Granular (por servicio)
Independencia de equipos	Baja (muchas dependencias)	Alta (servicios autocontenidos)
Flexibilidad tecnológica	Baja (un stack principal)	Alta (políglota, por servicio)
Despliegues	Grandes, infrecuentes	Pequeños, frecuentes, independientes
Consistencia de datos	Fácil (una DB central)	Difícil (distribuidas, eventual)
Debugging	Sencillo (un proceso)	Complejo (rastreo entre servicios)

Lo que ganas:

• Independencia de equipos: Cada equipo puede ser dueño de uno o varios servicios, trabajando y desplegando sin pisar el código de otros.
• Escalabilidad granular: Solo escalas los servicios que necesitan más recursos, optimizando el uso de infraestructura.
• Flexibilidad tecnológica: Puedes usar el mejor lenguaje o base de datos para cada problema específico, sin ataduras al stack principal.

Lo que complicas:

• Complejidad de despliegue y operación: Necesitas orquestación, monitorización distribuida, gestión de logs centralizada y estrategias de despliegue avanzadas.
• Consistencia de datos: Asegurar que los datos son consistentes en diferentes bases de datos es un reto que requiere patrones como la consistencia eventual y compensaciones.
• Comunicación entre servicios: La latencia de red, los fallos de red, la gestión de versiones de API y los contratos de servicio se vuelven parte fundamental del diseño y la operación.

Mi criterio para decidir la arquitectura

Mi criterio es claro: empieza con un monolito y solo considera microservicios cuando los problemas de tu arquitectura monolítica son irresolubles de otra forma o cuando los beneficios superan claramente la complejidad añadida. Esto suele ocurrir cuando tienes un equipo grande (más de 10-15 desarrolladores con experiencia), necesitas escalar partes muy específicas de la aplicación a gran volumen, o tienes requisitos de fiabilidad y aislamiento que esta arquitectura no puede ofrecer.

No es una decisión que se tome al inicio del proyecto, sino cuando el dolor de esta arquitectura se vuelve insoportable. Y cuando se hace, la migración es gradual, extrayendo funcionalidades críticas o dominios de negocio bien definidos como servicios independientes. La gestión de la caché en entornos de servicios distribuidos es otro punto clave a considerar para el rendimiento, y tengo un artículo sobre cuándo la caché ayuda y cuándo estorba que lo explora a fondo.

Si estás evaluando cómo gestionar la seguridad y el acceso en un entorno de microservicios, te interesa leer sobre cómo gestionar certificados SSL automáticos con Let’s Encrypt y Traefik. Y si ya trabajas con APIs distribuidas, entender la implementación práctica del rate limiting en tu API es un paso esencial para la estabilidad y protección de tus servicios.