MongoDB
Explica cómo los drivers gestionan pools de conexiones, selección de servidor, timeouts y reutilización para evitar latencia y saturación en aplicaciones.
mantiene conocimiento de la topología y pools de conexiones hacia los miembros elegibles. Debe reutilizarse durante la vida del proceso. Crear y cerrar un cliente por request añade DNS, TLS, autenticación, sockets y presión sobre el servidor.
MongoClientproceso Node.js
→ un MongoClient reutilizado
→ pool por servidor/topología
→ operaciones concurrentesUn pool grande no hace más rápida una query; solo permite más operaciones simultáneas hasta que otra capa se satura.
Inicializa una vez:
const client = new MongoClient(uri);
await client.connect();
export const db = client.db('app');Cierra durante graceful shutdown:
process.on('SIGTERM', async () => {
await server.close();
await client.close();
});Jobs temporales sí pueden crear y cerrar un cliente por ejecución. Una API persistente no debe cerrarlo después de cada query.
El driver descubre primary, secondaries y cambios de estado. La URI debe incluir seed list, replica set o SRV correcto. El cliente actualiza routing después de elections.
No caches manualmente “el primary actual”. La topología cambia.
Limita conexiones concurrentes por pool. Aumentarlo puede ayudar cuando existe pool wait y el servidor tiene capacidad, pero también puede:
Capacidad total aproximada:
instancias × pools × maxPoolSizeNo configures 500 conexiones en 100 pods sin calcular el cluster.
Mantiene conexiones preparadas. Puede reducir cold-start, pero consume recursos incluso sin tráfico y amplifica despliegues. Úsalo solo después de medir.
Cuando todas las conexiones están ocupadas, una operación espera checkout. Si el timeout vence, el error puede aparecer aunque MongoDB ejecute queries rápidas.
Mide por separado:
Aumentar el pool no corrige operaciones que retienen conexiones demasiado tiempo.
Tiempo para encontrar un servidor elegible. Cubre DNS, topology y failover, no la ejecución completa.
Apertura del socket/TLS.
Espera de actividad de red durante una operación. Un valor bajo puede interrumpir reportes válidos; uno enorme deja requests colgadas.
Límite server-side para una query compatible.
Coordina estos valores con el timeout HTTP y cancellation. El presupuesto externo no debe vencer mucho antes mientras la operación sigue consumiendo recursos.
Una conexión puede atender operaciones secuencialmente; el pool permite concurrencia. Cursors, transacciones y operaciones largas retienen recursos.
Evita:
Promise.all con miles de queries;Aplica límites de concurrencia en aplicación.
Cada instancia warm puede reutilizar un cliente global. El problema es crear uno por invocation o desplegar tantas instancias que la suma de pools exceda capacidad.
Usa caching compatible con el runtime, limita autoscaling y observa conexiones. No serialices sessions entre instancias.
En desarrollo, frameworks pueden reevaluar módulos. Conserva una promesa/client global en modo dev para evitar pools duplicados. En producción usa inicialización normal.
Ocurren cuando muchas instancias reconectan al mismo tiempo después de:
Mitigaciones:
El driver mantiene conexiones a miembros según topología. Leer de secondaries no crea una capacidad gratis; cada replica necesita recursos y puede aumentar lag. Configura read preference por caso de uso.
Observa:
Correlaciona con deploys y scaling.
Orden:
marcar instancia no ready
→ dejar de aceptar requests
→ esperar requests activos
→ cerrar cursors/workers
→ cerrar MongoClient
→ terminar procesoCerrar el cliente primero convierte requests en errores.
maxPoolSize arbitrariamente alto;Promise.all sin límite;El pool administra concurrencia, no velocidad individual. Reutiliza un MongoClient, dimensiona capacidad a nivel de todo el fleet, coordina timeouts y limita operaciones concurrentes. Pool wait, server selection y query execution son latencias distintas y deben medirse por separado.
MongoDB con Node.js.