La arquitectura de MongoDB describe cómo una operación viaja desde una aplicación hasta los datos persistidos y qué componentes participan en ese recorrido. Comprenderla evita tratar la base como una caja negra y ayuda a diagnosticar errores de conexión, consultas lentas, problemas de durabilidad, lag de replicación o distribución deficiente.
Una aplicación nunca escribe directamente en los archivos de MongoDB. Utiliza un driver, el driver selecciona un servidor y envía un comando, el proceso mongod o el router mongos interpreta la operación, el query planner decide cómo ejecutarla y el storage engine administra memoria, journal y archivos de datos.
Texto
aplicación
↓
driver
↓
mongod o mongos
↓
query planner y executor
↓
WiredTiger
↓
cache, journal y archivos de datos
Una base de datos debe aceptar operaciones concurrentes, encontrar datos con eficiencia, mantener consistencia, recuperarse después de fallos y, cuando sea necesario, replicar o distribuir información entre varios nodos.
Sin capas separadas, cada aplicación tendría que resolver por sí misma tareas como:
mantener conexiones y reconectarse;
detectar qué nodo es primary;
serializar valores a un formato persistible;
elegir un índice;
coordinar acceso concurrente;
escribir journal y checkpoints;
replicar cambios;
enrutar consultas hacia el shard correcto.
MongoDB distribuye esas responsabilidades entre componentes especializados.
mongos aparece en un sharded cluster. No almacena los documentos de la aplicación. Funciona como router:
Texto
cliente
↓
mongos
├── shard A
├── shard B
└── shard C
Utiliza metadata de los config servers para saber qué rangos pertenecen a cada shard. Si una query incluye suficiente información de la shard key, puede dirigirla a uno o pocos shards. Si no, puede necesitar consultar muchos shards y combinar los resultados.
WiredTiger es el storage engine predeterminado. Administra páginas, compresión, cache, checkpoints, snapshots y concurrencia interna. Trabaja junto con el sistema operativo y el journal.
MongoDB no lee necesariamente cada documento desde disco en cada consulta. Parte del working set puede permanecer en la cache de WiredTiger o en la cache del sistema operativo.
El journal registra cambios para apoyar recuperación ante un crash. Los checkpoints representan estados consistentes periódicos de los archivos de datos.
Simplificando el proceso:
Texto
write aceptada
↓
cambio en memoria
↓
registro de durabilidad según write concern
↓
journal y checkpoint
↓
recuperación posible después de un crash
El comportamiento observable depende del write concern, journaling, replication y versión. Journal no es un backup y no protege contra un borrado lógico correctamente replicado.
El driver selecciona un servidor compatible con la topología y read preference.
Serializa el filtro y las opciones a BSON.
mongod recibe el comando y comprueba permisos.
El query planner busca planes candidatos.
El executor recorre el índice o la colección.
WiredTiger obtiene las páginas necesarias desde cache o almacenamiento.
El servidor entrega el primer batch.
El driver expone un cursor y solicita batches adicionales cuando el consumidor avanza.
Una consulta lenta puede deberse a cualquiera de estas capas: selección de servidor, falta de índice, working set frío, sort costoso, demasiados documentos examinados o red lenta.
El servidor valida permisos, filtro, update y schema validator.
MongoDB localiza el documento.
La condición stock >= 2 funciona como precondition concurrente.
El cambio se aplica de forma atómica al documento.
La operación se registra para durabilidad y replication.
La respuesta depende del write concern configurado.
Recibir una respuesta no significa necesariamente que todos los miembros hayan persistido el cambio. Esa garantía depende de w, journaling y estado del replica set.
Un único mongod. Es útil para aprendizaje o ciertos entornos locales, pero no ofrece failover automático ni las capacidades completas que dependen de replica sets.
Un conjunto de procesos mongod que mantienen copias de los mismos datos. Normalmente existe un primary que recibe escrituras y secondaries que replican el oplog.
Texto
primary
/ \
secondary secondary
Si el primary deja de estar disponible, los miembros elegibles pueden realizar una election. Replication mejora disponibilidad, pero no reemplaza una política de backup.
Distribuye colecciones entre shards. Cada shard normalmente es un replica set. Además existen routers mongos y config servers.
Texto
application
↓
mongos
↓
config metadata
↓
shards, cada uno replicado
Sharding añade capacidad horizontal y complejidad operativa. No debería adoptarse antes de entender query patterns, índices, tamaño del dataset y límites de un replica set bien configurado.
MongoDB Atlas es una plataforma administrada. Automatiza parte del aprovisionamiento, backups, monitoring, upgrades y networking. El servidor sigue siendo MongoDB, pero Atlas añade servicios y capacidades propias.
Self-hosted ofrece mayor control sobre infraestructura y configuración, pero el equipo asume operación, seguridad, upgrades, backups, restauraciones y capacity planning.
La elección no cambia fundamentos como BSON, documentos, índices o atomicidad por documento.
El driver puede detectar el cambio de topología y reintentar ciertas retryable writes. La aplicación debe distinguir errores transitorios, resultados desconocidos y operaciones no idempotentes.
MongoDB seguirá funcionando, pero aumentarán lecturas desde almacenamiento y evictions. El diagnóstico requiere métricas de cache, I/O y query patterns; no basta con mirar la cantidad total de datos.
Replication puede mantener disponibilidad frente a algunos fallos, pero la recuperación frente a errores lógicos, ransomware o pérdida completa requiere backups probados.
La arquitectura de MongoDB conecta aplicación, driver, procesos del servidor, planner, storage engine y topología distribuida. Cada capa resuelve un problema diferente y cada una puede introducir costes o fallos.
Comprueba lo aprendido
¿Qué responsabilidad pertenece al driver y cuál al query planner?
¿Por qué mongos no debe considerarse un lugar donde viven documentos?
¿Qué diferencia existe entre journal, replication y backup?
Una consulta es rápida en un entorno pequeño y lenta en producción. ¿Qué capas revisarías?
¿Por qué un standalone no representa una arquitectura de alta disponibilidad?