MongoDB
Integra documentos, access patterns, consultas, índices, consistencia, replicación, sharding, seguridad y operación en un modelo completo de MongoDB.
MongoDB se diseña desde el dominio y los access patterns, no desde una lista aislada de colecciones. Cada decisión —documentos, índices, consistencia, seguridad y operación— debe responder a cómo se usa el dato y cómo puede fallar.
problema de negocio
→ invariantes y access patterns
→ límites documentales y tipos BSON
→ queries y escrituras
→ índices y planes
→ consistencia y topología
→ seguridad y operación
→ medición y evoluciónEl modelo mental completo evita optimizar una capa mientras se rompe otra.
Antes de abrir MongoDB, escribe:
Ejemplo de invariantes:
stock nunca negativo
SKU único por negocio
una orden conserva el precio vendido
un usuario no accede a otro tenant
repetir un pago no duplica el cobroEstas reglas determinan índices unique, updates condicionales, snapshots, autorización e idempotencia.
Por cada operación define:
filtro + sort + projection + limit + frecuencia + consistenciaEjemplo:
listar 20 órdenes pending
por businessId y branchId
ordenadas por createdAt DESC, _id DESCEsta descripción guía documento e índice:
{ businessId: 1, branchId: 1, status: 1, createdAt: -1, _id: -1 }No diseñes un índice antes de conocer la query completa.
Pregunta:
Es apropiado cuando el dato es dependiente, acotado y se usa con el padre.
{
orderId,
items: [
{ productId, nameAtPurchase, quantity, unitPrice }
]
}Los items de una orden son snapshots históricos y pertenecen a ella.
Úsalas cuando el dato tiene lifecycle independiente, alta cardinalidad o acceso propio.
{ orderId, customerId }Una referencia no crea foreign key. Debes manejar documentos missing, autorización e integridad.
Duplica deliberadamente cuando mejora una lectura y existe source of truth, política de staleness y reconciliación.
No confundas snapshot histórico con copia sincronizada.
Toda colección y array debe tener una expectativa:
items por orden: máximo 100
branches por negocio: decenas
movimientos de inventario: ilimitados → colección separadaSin límites, aparecen documentos gigantes, multikey explosion, contention y queries impredecibles.
Busca outliers, no solo promedios.
String 'false', boolean false, null y missing no son equivalentes.
El tipo afecta matching, sort, índices, aggregations y serialización.
input no confiable
→ validación runtime
→ lógica de dominio
→ documento persistido
→ server validationTypeScript ayuda al compilador. Mongoose aplica reglas a sus propias operaciones. $jsonSchema e índices protegen el servidor frente a otros writers.
Durante una evolución usa expand–migrate–contract y lectores compatibles con varias versiones.
MongoDB garantiza atomicidad a nivel de un documento. Aprovecha operadores:
$set;$inc;$push y $addToSet con límites;findOneAndUpdate.Ejemplo de stock:
db.inventory.updateOne(
{
businessId,
branchId,
productId,
available: { $gte: quantity }
},
{
$inc: {
available: -quantity,
reserved: quantity
}
}
);La condición y el cambio ocurren juntos. Read-modify-write sin precondition introduce carreras.
Una transacción es razonable cuando varias escrituras acotadas deben confirmar o abortar juntas.
reservar inventario
+ crear orden
+ registrar movimientos
+ guardar outbox
→ commitMantén callbacks cortos, pasa session a cada operación y evita paralelismo o efectos externos.
El driver puede reintentar el callback; la lógica debe tolerarlo.
La red puede fallar después de que MongoDB confirme. Un timeout no significa rollback.
Usa una clave de operación protegida por índice unique:
{ businessId: 1, idempotencyKey: 1 }Ante retry, devuelve el resultado anterior o un conflicto si el payload cambió.
Para eventos y workers, guarda operationId y deduplica efectos.
MongoDB no comparte una transacción con email, pagos o mensajería.
transaction
→ entidad + outbox
→ commit
→ worker idempotente
→ efecto externoEl procesamiento es al menos una vez; tanto productor como consumidor deben tolerar duplicados.
Un índice intercambia memoria, disco y coste de escritura por acceso eficiente.
Evalúa:
ESR es una heurística, no una receta absoluta.
No crees un índice por campo ni uno gigante para todas las queries.
Observa:
nReturned;totalKeysExamined;totalDocsExamined;IXSCAN ≠ eficiente automáticamentePrueba casos típicos, vacíos, rangos amplios y outliers. Explain no reemplaza una prueba de carga ni métricas de la aplicación.
Devuelve solo campos necesarios y limita resultados. Una projection reduce red y deserialización; una covered query puede evitar leer documentos.
En Mongoose, lean() reduce hydration en Node.js, pero no cambia el plan del servidor.
Usa cursor pagination con sort estable en lugar de skip profundo.
Define qué confirmación espera una escritura: nodo, journal, mayoría y timeout.
Define la garantía de visibilidad de la lectura.
Define qué miembros pueden atenderla.
No elijas una configuración global por costumbre. Una respuesta de catálogo, un pago y un reporte tienen necesidades distintas.
Retryable writes y transaction retries ayudan con fallos transitorios, pero no convierten cualquier operación en exactamente una vez.
Clasifica:
No añadas un retry genérico alrededor de toda la aplicación.
Un replica set ofrece copias, elections y base para transactions/Change Streams.
No protege contra:
Necesitas backups independientes y restore tests.
Observa lag, oplog window, majority y estado de todos los miembros.
Considera sharding cuando un replica set optimizado no sostiene capacidad, localidad o volumen.
Una shard key debe evaluar:
Queries sin shard key pueden hacer scatter-gather. Sharding no corrige un mal schema o índice.
{ _id: resourceId, businessId: session.businessId }El scope debe aplicarse en:
$lookup;El businessId viene del contexto autenticado, no del body.
Roles de MongoDB protegen recursos del servidor; la aplicación protege reglas por usuario y tenant.
Nunca pases filtros, updates, sort, projection o pipelines completos desde una request.
const filter = {
businessId: auth.businessId,
status: input.status
};Valida runtime, limita $in, rangos, pagination y regex. TypeScript y casting del ODM no impiden operator injection.
MongoClient mantiene topology y pools. Reutilízalo por proceso.
Mide:
El pool permite concurrencia, no acelera una query individual. Calcula conexiones de todo el fleet y evita Promise.all() ilimitado.
Separa:
Una repository debe exponer operaciones con intención, no Filter<T> genérico.
Mongoose aporta ergonomía, pero no cambia las garantías del servidor ni protege writers externos.
Una migration debe ser:
Guarda checkpoints después de batches confirmados. Separa backfill de cleanup y conserva lectores compatibles hasta terminar.
Conecta síntomas con capas:
request lento
→ pool wait
→ query plan
→ working set/cache
→ disk
→ replication/topologíaMide percentiles, no solo promedios.
Observa conexiones, throughput, cache/eviction, disk, lag, oplog, scans, slow queries, backups y crecimiento.
Cada alerta necesita owner y runbook.
WiredTiger administra páginas, cache, compression, MVCC, history store, checkpoints y journal.
Transacciones largas retienen versiones; índices excesivos amplían working set; storage lento aumenta checkpoint pressure.
Diagnostica workload y métricas antes de cambiar parámetros internos.
Ninguno reemplaza a los otros.
Define RPO y RTO. Incluye datos, índices, validators, users/roles, GridFS, key vault/KMS y metadata de sharding.
Un restore test termina cuando la aplicación funciona y se validan invariantes, no cuando la herramienta deja de copiar archivos.
Después de recuperar, reconcilia sistemas externos y eventos posteriores.
Coordina servidor, FCV, drivers, Mongoose y herramientas.
driver compatible
→ backup/restore
→ staging
→ rolling binary upgrade
→ observación
→ FCV
→ nuevas featuresConservar FCV anterior preserva una ventana de evaluación. No actualices todos los componentes y actives nuevas capacidades en un solo cambio.
Text search, MongoDB Search y Vector Search resuelven problemas distintos.
Vector Search necesita embeddings, chunking, filters, versionado, evaluación y control de costes.
La búsqueda nunca reemplaza autorización ni debe ser source of truth para confirmar una escritura.
Define invariantes, escalabilidad, fallos, SLOs, partición y recuperación. MongoDB implementa una parte del sistema.
Gestiona validación, lifecycle del cliente, concurrencia, timeouts, cancellation, errors y DTOs.
Añade schemas, hydration, population y middleware. Debe permanecer como una capa explícita sobre el driver.
Ofrece un modelo relacional con constraints, joins y transacciones fuertes por defecto. No existe una base universalmente superior: compara access patterns, integridad, consultas y operación.
Hace reproducible el proceso, pero volumes, replica sets, secrets, backups y upgrades siguen siendo responsabilidades de operación.
Repositories, outbox, idempotencia y migrations conectan persistencia con casos de uso sin esconder las garantías reales.
Para una nueva funcionalidad:
Diseña un sistema de reservas de citas:
un usuario elige sede, servicio y horario
no debe existir doble reserva
el pago puede fallar
la cita puede cancelarse
se envían recordatoriosDebes decidir:
No empieces por elegir collections; empieza por las invariantes.
$lookup en cada request;MongoDB no se domina memorizando comandos. Se domina conectando dominio, documentos, queries, índices, concurrencia, topología y operación. Una decisión correcta hace explícitos sus límites, protege invariantes bajo concurrencia, se verifica con evidencia y tiene una estrategia para evolucionar y recuperarse.
Usa esta nota como mapa de navegación. Ante una decisión nueva, vuelve al proceso: requisito → invariantes → access patterns → documento → operación → índice → consistencia → seguridad → operación. Si puedes explicar y verificar cada paso, el diseño es defendible.