Para la mayoría de productos nuevos, la mejor elección es un monolito modular: una sola aplicación que se despliega de una vez, dividida por dentro en módulos con fronteras que se vigilan de forma automática. Los microservicios compensan cuando tienes varios equipos que necesitan desplegar por separado, partes del sistema que escalan de forma muy distinta y la madurez operativa para gestionar un sistema distribuido. Es la primera decisión que tomamos en cualquier proyecto de desarrollo de aplicaciones web en Madrid.
Elegir mal sale caro en las dos direcciones. Empezar con microservicios obliga a pagar desde el primer día redes, colas, observabilidad y despliegues coordinados que un producto sin usuarios todavía no necesita, algo que cualquier empresa de software a medida en Madrid debería explicarte antes de presupuestar. Empezar con un monolito sin fronteras produce, dos años después, un bloque en el que cualquier cambio rompe algo en otra parte y del que no se puede extraer nada sin reescribirlo.
Al terminar sabrás qué criterios usar para decidir, cómo mantener las fronteras de un monolito modular y qué señales indican que ha llegado el momento de sacar un servicio, criterios que conviene exigir a cualquier empresa de desarrollo web en Madrid.
Qué es un monolito modular
Un monolito modular es una aplicación que se despliega como una sola unidad pero está organizada en módulos que corresponden a áreas de negocio, como pedidos, facturación o clientes. Cada módulo expone una API pública al resto y oculta su funcionamiento interno. Lo que lo diferencia de un monolito tradicional es que esas fronteras se comprueban automáticamente.
Es la arquitectura por la que empezamos la mayoría de los proyectos de desarrollo de software a medida para empresas en España, porque permite avanzar rápido sin cerrar la puerta a separar piezas más adelante.
Shopify, que opera uno de los monolitos más conocidos, lo definió en su artículo Deconstructing the Monolith como un sistema en el que todo el código alimenta una única aplicación y hay fronteras estrictamente aplicadas entre dominios.
Qué son los microservicios y qué cuestan
Los microservicios dividen el producto en aplicaciones independientes, cada una con su propio despliegue, normalmente en contenedores Docker, y su propia base de datos, que se comunican por la red. La ventaja principal es la autonomía: un equipo puede desplegar su servicio sin coordinarse con los demás, y cada servicio escala por separado.
El precio es la complejidad. La guía de arquitectura de microservicios de Microsoft lo resume así: cada servicio es más sencillo, pero el sistema en conjunto es más complejo, y el estilo exige una cultura DevOps madura. Además, una operación que toca varios servicios difícilmente puede ser una transacción atómica, así que la consistencia de los datos pasa a ser un problema de diseño.
Ese coste también es económico. En nuestra guía de cuánto cuesta desarrollar un software a medida estimamos entre 1.000 y 3.000 € al mes de mantenimiento de infraestructura DevOps para una arquitectura de microservicios, antes de sumar horas de desarrollo.
Lo que dicen los casos reales
Martin Fowler, en su artículo MonolithFirst, observa que casi todas las historias de éxito con microservicios empezaron con un monolito que creció demasiado y se dividió. Sam Newman, autor de referencia sobre el tema, dijo en la QCon de Londres de 2020 que los microservicios deberían ser el último recurso y no la opción por defecto, y que a la mitad de sus clientes les había aconsejado no usarlos.
El caso más citado del camino inverso es el del equipo de monitorización de Prime Video. Según la crónica de InfoQ sobre su cambio de arquitectura, al pasar de un sistema distribuido en funciones serverless a un único proceso redujeron un 90 % los costes operativos de ese servicio.
Nada de esto significa que los microservicios sean un error. Empresas con cientos de ingenieros los necesitan porque su problema es organizativo: coordinar equipos. La ley de Conway lo explica bien: la estructura de un sistema tiende a copiar la estructura de comunicación de la organización que lo construye. Por eso un buen estudio de software a medida en Madrid pregunta primero cómo es tu equipo.
Cómo elegir: los criterios que importan
Estos son los criterios que usamos para decidir, en este orden, y encajan con las claves para elegir una empresa de software a medida:
- Tamaño del equipo: con un solo equipo de desarrollo, la autonomía de despliegue no aporta casi nada. Con varios equipos que se pisan en cada entrega, empieza a aportar.
- Claridad de los dominios: si todavía no sabes dónde acaban «pedidos» y empieza «facturación», cualquier frontera física será provisional. Es más barato moverla dentro de un monolito que entre dos servicios.
- Escala desigual: si una parte del sistema recibe cien veces más tráfico que el resto, por ejemplo un catálogo público frente a un panel interno, puede merecer su propio despliegue.
- Requisitos de aislamiento: datos muy sensibles, como pagos, pueden justificar un servicio separado para reducir el alcance de auditorías y riesgos.
- Madurez operativa: despliegue automatizado, monitorización y trazas entre servicios. Sin eso, los microservicios multiplican los incidentes.
Cuándo empezar con monolito modular, que además deja más margen en el presupuesto de software a medida:
- Producto nuevo con un equipo pequeño o mediano.
- Dominios que todavía van a cambiar con lo que aprendas de los usuarios.
- Presupuesto que prefieres invertir en funcionalidades y no en infraestructura.
Cuándo empezar con servicios separados, algo más habitual en plataformas grandes como un marketplace con varios equipos:
- Varios equipos independientes desde el primer día.
- Una pieza con escala o requisitos de seguridad claramente distintos.
- Una plataforma ya existente a la que el producto nuevo se conecta como servicio.
Cómo mantener las fronteras de un monolito modular
Las fronteras que dependen de la disciplina se rompen con la primera prisa. Por eso se vigilan con herramientas en la integración continua: Spring Modulith en proyectos Java, Packwerk en Rails y dependency-cruiser o eslint-plugin-boundaries en TypeScript. Dentro de cada módulo, la organización del código es otra decisión; la arquitectura hexagonal para proteger el núcleo de cada módulo encaja muy bien aquí.
CodeZone Pro Tip: haz que la integración continua falle si un módulo se salta la frontera de otro
// Fronteras del monolito modular: se comprueban en cada pull request
module.exports = {
forbidden: [
{
name: "solo-api-publica",
comment: "Un módulo solo puede usar la API pública (index.ts) de otro, nunca su carpeta internal",
severity: "error",
from: { path: "^src/modules/([^/]+)/" },
to: { path: "^src/modules/([^/]+)/internal/", pathNot: "^src/modules/$1/" },
},
{
name: "sin-ciclos",
comment: "Si facturación depende de pedidos, pedidos no puede depender de facturación",
severity: "error",
from: {},
to: { circular: true },
},
{
name: "compartido-sin-dominio",
comment: "El código compartido no conoce ningún módulo de negocio",
severity: "error",
from: { path: "^src/shared/" },
to: { path: "^src/modules/" },
},
],
options: { tsPreCompilationDeps: true },
};
// En la CI: npx depcruise src --config .dependency-cruiser.cjs (falla si se rompe una frontera)Esta configuración de dependency-cruiser convierte las fronteras en una regla que la máquina comprueba en la revisión de cada pull request: si alguien importa el código interno de otro módulo, crea una dependencia circular o mete lógica de negocio en el código compartido, la integración continua falla antes de llegar a producción. Para el negocio, significa que dentro de dos años podrás extraer un módulo como servicio sin reescribirlo, porque sus dependencias ya están limpias.
Los datos también tienen fronteras
El código es la mitad del trabajo. Si el módulo de pedidos consulta directamente las tablas de facturación, la frontera existe en el código pero no en los datos, y extraerlo más adelante obliga a desenredar consultas por todo el sistema. La práctica que mejor funciona es que cada módulo sea dueño de sus tablas, por ejemplo con un esquema propio en la base de datos, y que el resto acceda a esos datos solo a través de su API pública. Sigue siendo una única base de datos, fácil de respaldar y de consultar para informes, pero con la misma disciplina que tendrían dos servicios separados.
Cuándo extraer un módulo como servicio
La extracción tiene sentido cuando aparece una razón medible, como una factura de infraestructura en Google Cloud o Cloudflare que se dispara, y no por calendario. Shopify contó en 2020, en su artículo «Under Deconstruction», que entre las pocas piezas separadas del monolito como servicios estaban el renderizado de la tienda y el almacenamiento de tarjetas. Señales que suelen justificarlo:
- Un módulo necesita escalar muy por encima del resto y encarece toda la infraestructura.
- Un equipo concreto está bloqueado por los despliegues de los demás de forma recurrente.
- Una parte tiene requisitos de seguridad o cumplimiento que conviene aislar.
- Un módulo necesita otra tecnología, por ejemplo un proceso de datos o de IA.
Si el módulo tiene fronteras limpias, extraerlo es un proyecto acotado que sigue el mismo patrón que usamos para sustituir partes de una aplicación antigua sin parar la operativa: fachada, convivencia y paso gradual del tráfico.
Cómo se aplica a productos habituales
Imagina tres productos nuevos que llegan con la misma pregunta a una agencia de desarrollo de software en Madrid.
Un SaaS B2B en fase inicial, con un equipo de cuatro desarrolladores: monolito modular con módulos por dominio y una base de datos con esquemas separados. Si más adelante hace falta separar algo, el primer candidato es el módulo de informes. En las fases del desarrollo de un SaaS contamos cómo encaja con la hoja de ruta.
Un ERP a medida para una empresa mediana: monolito modular sin duda. Sus módulos comparten muchos datos y transacciones, como un pedido que descuenta stock y genera una factura, y separarlos en servicios complicaría justo lo que más importa. Lo explicamos en cómo se plantea un ERP a medida por fases, y si la empresa aún trabaja sobre Excel, el primer paso es sustituir las hojas de cálculo que hacen de sistema.
Una plataforma con un portal público y una parte interna: un solo backend modular suele bastar para el portal de clientes conectado con el ERP y para el panel interno con roles y auditoría. Si el portal va a recibir mucho más tráfico, su capa de lectura puede desplegarse aparte. Y si la plataforma incluye apps, el backend es el mismo; en cómo elegir el backend de una app comparamos opciones.
Para una visión más general de los estilos de backend disponibles, tienes los tipos de arquitectura backend en 2026.
El Riesgo de Elegir la Arquitectura por Moda
Los microservicios mal elegidos fallan cuando el presupuesto se va en infraestructura, cada cambio exige coordinar varios despliegues y nadie sabe dónde empieza un error que cruza servicios, lo que encarece el soporte y mantenimiento de software en Madrid. Un monolito sin fronteras falla más tarde y de forma más silenciosa, cuando ya no se puede tocar nada. Ambos problemas se evitan con módulos claros desde el principio y una razón medible antes de distribuir.
En Codezone diseñamos la arquitectura de productos nuevos con backends que sirven igual a la web que a las apps móviles nativas y multiplataforma en Madrid. Si estás a punto de empezar un producto y dudas entre estas dos opciones, cuéntanos qué vas a construir y con qué equipo y te ayudamos a decidir con criterios concretos.
