Arquitectura monolítica: una unidad desplegable, una base de datos
La arquitectura monolítica en un lienzo interactivo: una aplicación desplegable con módulos de interfaz, lógica de negocio y acceso a datos, una base de datos compartida y el techo de escalado que eso produce.
Un monolito es una aplicación que se construye y se despliega como una sola unidad: la interfaz, la lógica de negocio y el acceso a datos corren todos en un único proceso contra una base de datos compartida, y escalar significa replicarlo todo.
Arquitectura monolítica: una unidad desplegable, una base de datos
El lienzo interactivo de FlowJam de esta explicación: cada carril, cada fila y cada flecha de arriba forma parte de un diagrama real de QueryChart que puedes abrir y editar.
Cómo leer este diagrama
- Sigue la petición desde el cliente, baja por los tres módulos, entra en la base de datos compartida y vuelve a salir: una sola ida y vuelta por un solo proceso.
- Los módulos están dentro de la banda «Aplicación monolítica» porque comparten proceso y despliegue; esa contención es la definición de un monolito.
- La caja final es la conclusión: el camino de escalado va hacia el lado y duplica la aplicación entera.
El camino de la petición por un solo proceso
«El cliente envía una petición» entra en «La petición entra en la única aplicación desplegable», y después vienen «El módulo de interfaz enruta y renderiza», «El módulo de lógica de negocio la procesa» y «El módulo de acceso a datos consulta la base de datos», todo dentro del único carril «Aplicación monolítica». Los tres módulos se dibujan apilados para mostrar que comparten memoria, proceso y despliegue: nada en ellos se puede desplegar por separado.
La base de datos compartida
«Una sola base de datos compartida lo guarda todo» es la segunda característica que define al monolito. Todos los módulos leen y escriben el mismo esquema, lo que hace directos los joins y las transacciones: la razón de que un monolito sea tan productivo al principio. El grupo «Base de datos» queda fuera de la banda de la aplicación porque es un proceso aparte, pero es compartido: el acoplamiento vive en el esquema del que depende cada módulo.
El techo de escalado
«La respuesta vuelve por los mismos módulos» cierra la ida y vuelta, y «Escalar significa replicar la aplicación entera» es el veredicto. Una funcionalidad con mucha carga obliga a llevar todo el código y su pool de conexiones a otro servidor, y desperdicia capacidad en las partes que no tienen carga. Esa ineficiencia, y no un fallo técnico, es lo que acaba motivando la división en microservicios.
Relaciones clave y conclusiones
- Todos los módulos comparten un proceso, un código y un despliegue: esa contención es la definición.
- La base de datos compartida acopla cada módulo a un único esquema.
- Las peticiones recorren todos los módulos en una sola ida y vuelta: no hay ninguna llamada de servicio aparte.
- El escalado es tosco: se duplica la aplicación entera, tenga carga esa funcionalidad o no.
- La velocidad de desarrollo del monolito es real; el techo de escalado es lo que entrega a cambio.
Cuándo usar este diagrama
- Explicar por qué la aplicación de un equipo es difícil de escalar aunque sea fácil de desarrollar.
- Enseñar el contraste que hace comprensibles los microservicios: la división solo tiene sentido frente al techo del monolito.
- Documentar la estructura de un sistema heredado antes de planificar cómo dividirlo.
Cómo funciona
Renombra los módulos con los de tu código
Sustituye interfaz, lógica de negocio y acceso a datos por tus capas y módulos reales, y añade los que los tres genéricos no cubren.
Marca los cuellos de botella de escalado reales
Anota en la caja final la funcionalidad o la consulta concreta que obliga a escalar, y la capacidad que se desperdicia al replicar la aplicación entera.
Dibuja los candidatos a extracción
Añade una frontera discontinua alrededor del módulo que sea el mejor candidato a convertirse en un servicio, con una nota sobre qué acoplamiento habría que cortar.
Enlaza con la alternativa de microservicios
Una vez marcados los candidatos a extracción, enlaza con el diagrama de microservicios para comparar la arquitectura de destino en paralelo.
Preguntas frecuentes
¿Qué es una arquitectura monolítica?
Un monolito es una aplicación cuya interfaz, lógica de negocio y acceso a datos se construyen, se despliegan y se escalan como una sola unidad: un único código que produce un único artefacto desplegable y que corre contra una base de datos compartida. El diagrama muestra la petición recorriendo los tres módulos dentro de un solo carril de aplicación, porque esa contención es la definición.
¿Por qué los equipos empiezan con un monolito?
Porque, para la mayoría de los equipos y durante la mayor parte de la vida de una aplicación, un monolito es la forma más rápida de entregar. No hay red entre los módulos, el esquema compartido hace simples los joins y las transacciones, y el despliegue es un solo artefacto. La caja de la base de datos compartida del diagrama lo dice directamente: el intercambio solo se vuelve negativo cuando el escalado independiente o la autonomía de los equipos pasa a ser la restricción que limita.
¿Cuál es el problema principal de un monolito?
El techo de escalado y el acoplamiento. Escalar significa replicar la aplicación entera, así que una funcionalidad con mucha carga desperdicia capacidad en todo lo demás, y cada cambio toca un código y un esquema de los que depende todo el mundo. A medida que crecen el equipo y el código, esos dos efectos frenan el despliegue y obligan a coordinarse: las condiciones en las que los equipos empiezan a extraer servicios.
¿Cómo se convierte un monolito en microservicios?
Poco a poco, extrayendo una capacidad cada vez. El primer paso es identificar un módulo que pueda sostenerse solo —con sus datos acotados—, y después darle su propia base de datos, una API y, con el tiempo, despliegue independiente. El paso de candidato a extracción del diagrama modela exactamente esto: marca el módulo, corta el acoplamiento y divide. El error es reescribir el monolito entero de una vez, que es como fracasan las migraciones.
Edita este diagrama en QueryChart (FlowJam)
Abre ese mismo lienzo del monolito como tu propio diagrama, renombra los módulos con los de tu código y traza tu cuello de botella de escalado.