Los monolitos modulares están sustituyendo a los microservicios en equipos de ingeniería medianos
Durante la mayor parte de la última década, dividir una aplicación en microservicios se consideraba la decisión responsable, lo que se hacía una vez que la escala importaba de verdad. En 2026, un número creciente de equipos de ingeniería está revirtiendo silenciosamente esa decisión, no abandonando los límites de servicio, sino colapsándolos de nuevo en una sola unidad desplegable con una separación interna estricta: el monolito modular.
El ejemplo público más claro sigue siendo el equipo de Prime Video de Amazon, que en 2023 trasladó su servicio de análisis de calidad de vídeo de una canalización distribuida basada en Lambda y microservicios a un único proceso monolítico. El equipo informó de una reducción de costes de infraestructura de aproximadamente el 90% para ese servicio específico, junto con una depuración mucho más sencilla.
Por qué el péndulo volvió atrás
Los microservicios resuelven un problema específico: capacidad de despliegue y escalado independientes para equipos lo bastante grandes como para que una base de código compartida se convierta en un cuello de botella de coordinación. Para una organización de ingeniería de 200 personas dividida en docenas de equipos autónomos, esa compensación tiene sentido. Pero para un equipo de 15 personas ejecutando 40 microservicios, la sobrecarga operativa se come el supuesto beneficio.
Basecamp y Shopify han descrito públicamente mantenerse en, o volver a, un modelo de «monolito majestuoso» en lugar de dividirse en docenas de servicios, citando el mismo razonamiento: la mayoría de sus rutas de solicitud no necesitan escalado independiente.
Cómo es realmente un monolito modular
Un monolito modular no es «rendirse y escribir código espagueti en un solo archivo». Es una única aplicación desplegable organizada internamente en paquetes o módulos con límites explícitos y aplicados, normalmente un módulo por dominio de negocio (facturación, inventario, notificaciones). Cada módulo posee su propia capa de acceso a datos y expone una interfaz interna estrecha a otros módulos.
Esto proporciona la mayoría de los beneficios que la gente quería originalmente de los microservicios, sin el impuesto de los sistemas distribuidos: sin latencia de red entre módulos, sin manejo de fallos parciales para llamadas que antes eran llamadas a funciones.
Cuándo los microservicios siguen justificando su coste
El argumento honesto a favor de los microservicios sigue existiendo. Si un componente necesita escalar de forma independiente 50 veces más que el resto del sistema, separarlo es la decisión correcta. La regla práctica que ha surgido entre los equipos en 2026: por defecto, usa un monolito modular, y extrae un servicio solo cuando puedas nombrar el requisito específico de escalado, lenguaje o autonomía de equipo que lo justifique.
Conclusiones para equipos que reconsideran su arquitectura
Si tu equipo tiene menos de unos 50 ingenieros y ejecuta más de un puñado de servicios, audita qué servicios realmente tienen necesidades de escalado independientes frente a cuáles se dividieron por razones organizativas que ya no aplican. Mantén los límites de módulo; elimina los saltos de red.