Arquitectura monolítica · Mapas mentales
Arquitectura monolítica. Un mapa mental editable con ramas de colores, ideas secundarias y conexiones. Las líneas curvas muestran relaciones; las flechas aparecen cuando importa la dirección.
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 · Mapas mentales
El lienzo interactivo de MindMap 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 mapa mental
- Empieza por el tema central y sigue una rama de color para explorar sus ideas.
- Las líneas curvas muestran relaciones; las flechas aparecen cuando importa la dirección.
Client request
Esta rama reúne “Client sends a request”.
One application
Esta rama reúne “Request enters the single deployable application”, “Business logic module processes it”, “The response returns through the same modules”, “UI module routes and renders”, “Data access module queries the database”.
Shared database
Esta rama reúne “All modules share a single schema, which keeps joins and transactions simple — the main reason a monolith is so fast to build at first.”.
Scaling tradeoff
Esta rama reúne “One busy feature forces the entire codebase and database connection pool to be copied to another server — the scaling ceiling that pushes teams toward splitting it.”.
Conexiones entre ramas
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.
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
Adapta el tema central
Cambia el nombre del tema para adaptarlo a tu proyecto o clase.
Desarrolla las ramas
Edita las ideas y añade ejemplos o notas.
Conecta ideas relacionadas
Dibuja conexiones entre ramas; usa flechas cuando la dirección importe.
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.
Editar este mapa mental en QueryChart
Abre este mapa mental en un lienzo editable. Mueve ideas, añade ramas y dibuja conexiones.