MongoDB
Reúne antipatrones frecuentes de MongoDB relacionados con modelado, arrays sin límite, consultas sin índices, datos inconsistentes, seguridad y operación.
Un antipatrón no es una regla prohibida en todo contexto. Es una decisión que parece conveniente al inicio, pero acumula coste, inconsistencia o riesgo cuando crecen los datos, la concurrencia o el equipo.
comodidad local
→ comportamiento oculto
→ escala o fallo
→ deuda operacionalPara reconocerlo pregunta: qué access pattern intenta resolver, qué supuesto de cardinalidad hace, cómo falla y qué evidencia permitiría mantenerlo o reemplazarlo.
Documento:
{
productId,
reviews: [/* crece para siempre */]
}Problemas:
Alternativas:
reviews;Un array es válido si existe un máximo real pequeño y lifecycle compartido.
Guardar perfil, historial, archivos y analíticas juntos obliga a leer y reescribir información innecesaria.
Síntomas:
Corrige con projection, subset pattern, GridFS para archivos grandes o separación por lifecycle. No fragmentes documentos pequeños únicamente por imitar un modelo relacional.
“MongoDB es schemaless” conduce a mezclar:
{ price: 18000 }
{ price: '18000' }
{ price: null }El resultado rompe sort, aggregations, índices y código.
Defensa:
$jsonSchema;Flexibilidad debe permitir evolución, no ausencia de reglas.
Embeber relaciones con lifecycle independiente genera duplicación masiva y fan-out de updates. Ejemplo: copiar el catálogo completo dentro de cada orden.
Distingue:
La orden debe guardar nombre y precio vendidos, pero no todo el producto actual.
Convertir MongoDB en tablas con referencias para cada campo produce:
$lookup frecuentes;Embebe subdocumentos dependientes y acotados que se leen y escriben junto al padre.
{ businessId: 1 }
{ status: 1 }
{ createdAt: 1 }No equivale necesariamente al compound requerido por filtro y sort. Además aumenta writes, disco y cache.
Diseña índices por query shape:
{ businessId: 1, status: 1, createdAt: -1, _id: -1 }Verifica con explain y elimina redundantes mediante hidden indexes.
Más índices no significa más rendimiento. Cada escritura actualiza todos los índices relevantes y los multikey pueden multiplicar entradas.
Señales:
Mantén inventario, owner y propósito por índice.
Crear { createdAt: -1, businessId: 1 } para una query por tenant y fecha puede recorrer rangos amplios. El prefix y ESR/ERS importan.
No copies una regla mecánica: prueba igualdad, sort, range, selectividad y distribución.
find(filter).sort(sort).skip(100000).limit(20)El servidor debe atravesar resultados anteriores. La latencia crece con la página.
Usa cursor pagination con sort estable y tie-breaker _id.
{ name: { $regex: input, $options: 'i' } }Puede escanear muchas claves/documentos, consumir CPU y no ofrecer relevancia lingüística.
Alternativas:
Nunca aceptes regex arbitraria sin control.
Autopopulate y nested populate ocultan consultas y crean payloads enormes. Además, una referencia poblada puede cruzar tenants o quedar null.
Prefiere:
$lookup medido;Cuenta queries reales.
app.get('/orders', async () => {
const client = await new MongoClient(uri).connect();
// ...
await client.close();
});Genera DNS, TLS, autenticación y connection storms. Reutiliza un MongoClient por proceso y ciérralo durante graceful shutdown.
Aumentar maxPoolSize puede multiplicar concurrencia hasta saturar CPU, disco o límites de conexiones.
Calcula capacidad global:
instancias × conexiones por pool × miembrosMide wait queue y duración antes de ajustar.
leer stock 5
restar 4
guardar 1Dos requests pueden leer el mismo valor y vender de más.
Usa update condicional:
db.inventory.updateOne(
{ _id, stock: { $gte: quantity } },
{ $inc: { stock: -quantity } }
);Revisa matchedCount y utiliza transacción cuando la invariantes cruza documentos.
Las transacciones no arreglan un mal límite documental. Añaden sessions, retries, snapshots y mayor coste.
Usa primero atomicidad de un documento y operaciones condicionales. Reserva transacciones para invariantes multi-documento acotadas.
Enviar email, cobrar o publicar a una API dentro del callback puede repetirse en un retry o ocurrir antes de un abort.
Usa outbox:
transacción → datos + evento outbox
worker → efecto externo idempotentebuscar email
→ no existe
→ insertarDos requests pueden pasar. La garantía correcta es un unique index; la consulta previa solo mejora el mensaje.
Buscar por _id y comprobar businessId después expone una ventana de autorización y desperdicia lectura.
Filtro correcto:
{ _id: orderId, businessId: session.businessId }Aplica scope también en updates, aggregations, populate, Search y jobs.
Pasar req.body como filtro o update permite operator injection, campos protegidos y queries costosas.
Defensa:
No expongas Filter<T> como contrato HTTP.
Schemas, hooks y validators no protegen scripts, imports ni otros servicios. Además, rutas de update ejecutan reglas distintas.
Replica invariantes críticas con índices y server validation, y prueba operaciones reales.
Una query “rápida” con cien documentos puede ejecutar COLLSCAN. Un IXSCAN puede examinar millones de claves.
Compara:
nReturned;totalKeysExamined;totalDocsExamined;Un p50 saludable puede ocultar p99 terrible para tenants grandes. Mide percentiles, pool wait, cold cache y distribución.
Sharding añade shard key, balancer, routers, operaciones distribuidas y complejidad de backup. No corrige queries sin índices ni documentos mal modelados.
Primero optimiza replica set. Shardea cuando capacidad, locality o escala lo requieren y existe una shard key defendible.
Una key monotónica puede concentrar writes; una key de baja cardinalidad produce chunks desequilibrados; una key ausente en queries genera scatter-gather.
Evalúa cardinalidad, frecuencia, distribución, targeting y crecimiento.
Replica sets copian errores válidos: delete, corrupción lógica o ransomware. Necesitas backups independientes, PITR cuando aplique y restore tests.
Un job verde no prueba que archivos, claves, permisos e índices permitan recuperar dentro del RTO.
Restaura periódicamente y ejecuta checks funcionales.
Un script sin checkpoint, idempotencia ni throttling falla a mitad y deja datos mixtos.
Diseña batches, preconditions, retries, progreso y reconciliación. No ejecutes millones de updates desde una request HTTP.
Tags flotantes o upgrades simultáneos de servidor, driver y ODM eliminan una ruta clara de diagnóstico.
Fija versiones, prueba compatibilidad, conserva FCV anterior y activa features después.
Sin métricas de pool, query shapes, cache, disco, lag y backups, cualquier incidente se convierte en adivinanza.
Define SLOs, baselines, alertas accionables y runbooks.
Endpoints que permiten limit=100000, $in enorme, rangos ilimitados o exports síncronos pueden agotar memoria y conexiones.
Valida cardinalidad, usa streaming/backpressure, timeouts y jobs.
El contexto puede justificar una forma que normalmente sería riesgosa. La diferencia es que sus límites están explícitos y medidos.
$lookup sin medir;La mayoría de antipatrones nacen de ignorar cardinalidad, concurrencia o operación. MongoDB funciona mejor cuando los límites documentales, query shapes, índices y garantías están diseñados juntos. No corrijas por dogma: mide el coste, protege la invariantes y conserva una alternativa reversible.
Caso práctico: pedidos e inventario.