MongoDB
Define los patrones de lectura y escritura que guían el schema, los índices y la distribución de datos en MongoDB antes de diseñar colecciones.
Un describe cómo una aplicación necesita leer, filtrar, ordenar, proyectar, agregar y modificar datos. En MongoDB, los access patterns no son una optimización que se añade al final: son una entrada principal del diseño documental.
La pregunta inicial no es “¿qué entidades existen?”, sino:
¿Qué operaciones debe resolver el sistema, con qué frecuencia, sobre qué volumen y con qué garantías?
La respuesta orienta:
Diseñar únicamente a partir de entidades produce documentos que “se ven correctos”, pero que pueden ser costosos o imposibles de consultar con eficiencia.
Supón un sistema de pedidos que identifica estas entidades:
business
customer
order
product
order_itemEse inventario no responde todavía preguntas importantes:
Sin esas respuestas, no es posible decidir correctamente embedding, references, indexes o transacciones.
caso de uso
↓
query o command
↓
filtros + sort + proyección + actualización
↓
frecuencia + volumen + consistencia
↓
document boundary
↓
índice y estrategia operativaUn access pattern completo combina forma y contexto. La misma query ejecutada una vez al mes no tiene el mismo peso que una query ejecutada miles de veces por minuto.
Describe qué intenta conseguir el usuario o el sistema.
Ejemplos:
La operación debe expresarse antes de escribir código del driver.
Indican qué campos reducen el conjunto de documentos.
{
businessId: ObjectId('...'),
branchId: ObjectId('...'),
status: 'pending'
}Debe distinguirse igualdad, rango, existencia, array membership y condiciones compuestas. Esos detalles afectan índices y cardinalidad.
El orden determina si un índice puede entregar resultados ya organizados o si MongoDB necesita hacer un sort adicional.
{ createdAt: -1, _id: -1 }El tie-breaker _id evita ambigüedad cuando varios documentos comparten la misma fecha, especialmente en cursor pagination.
Define qué datos necesita realmente el consumidor.
{
customer: 1,
total: 1,
status: 1,
createdAt: 1
}La proyección influye en payload, seguridad y posibilidad de covered query. No debe utilizarse para esconder un documento mal dimensionado, pero sí para evitar transferir campos innecesarios.
Clasifica operaciones como:
El schema debe favorecer operaciones críticas sin intentar optimizar todas las consultas imaginables.
Pregunta cuántos valores pueden existir en una relación o conjunto:
Cardinalidad no es solo el valor promedio. También importa el peor caso y la distribución. Una tienda puede tener 10 categorías normalmente, pero un marketplace puede tener millones de productos.
Expresa qué tanto reduce un filtro.
businessId puede reducir a los documentos de un tenant.status: 'pending' quizá coincida con una pequeña fracción.active: true podría coincidir con casi toda la colección.Los campos poco selectivos no son inútiles, pero su posición y combinación en índices deben evaluarse con la query completa.
Registra:
Diseñar solo con datos de desarrollo oculta problemas que aparecen meses después.
Cada operación debe indicar qué debe ocurrir como una unidad.
Ejemplo:
vender 2 unidades
→ comprobar stock >= 2
→ descontar 2
→ impedir stock negativoEsto puede resolverse con un update condicional atómico sobre un documento:
db.products.updateOne(
{
_id: productId,
stock: { $gte: 2 }
},
{
$inc: { stock: -2 }
}
);Si la operación afecta varios documentos, debe evaluarse si rediseñar el boundary, aceptar consistencia eventual o utilizar una transacción.
Define cuánto tiempo vive la información y cómo se elimina:
Una política de retención cambia tamaño, índices y arquitectura.
Un access pattern puede documentarse así:
Nombre: Listar órdenes pendientes
Actor: store manager
Frecuencia: alta
Filtro: businessId, branchId, status
Orden: createdAt DESC, _id DESC
Proyección: customer, total, status, createdAt
Página: 20 elementos
Consistencia: read-after-write desde primary
Volumen: 5M órdenes, 20k pendientes
Crecimiento: 50k órdenes/día
SLA: p95 < 150 msLuego se deriva una query:
db.orders.find(
{
businessId,
branchId,
status: 'pending'
},
{
customer: 1,
total: 1,
status: 1,
createdAt: 1
}
).sort({
createdAt: -1,
_id: -1
}).limit(20);Y un índice candidato:
db.orders.createIndex({
businessId: 1,
branchId: 1,
status: 1,
createdAt: -1,
_id: -1
});El índice sigue la combinación de igualdad y sort de esta query. No se considera correcto solo por apariencia; debe validarse con datos representativos y explain('executionStats').
Supón que el listado necesita mostrar nombre del cliente. Existen varias opciones.
{
customerId: ObjectId('...')
}Ventaja: una fuente central del nombre actual.
Coste: el listado requiere otra query, batching, cache o $lookup.
{
customer: {
id: ObjectId('...'),
name: 'Laura Gómez'
}
}Ventaja: la orden es autosuficiente y conserva el nombre utilizado al comprar.
Coste: si el requisito exige mostrar siempre el nombre actual, debe definirse actualización, lectura adicional o separar nombre histórico de nombre vigente.
La decisión no nace de una regla genérica. Nace de qué significa ese dato en el caso de uso.
Optimizar una lectura puede aumentar coste de escritura.
Guardar customerName dentro de muchas órdenes acelera listados, pero un cambio global de nombre podría requerir fan-out.
Guardar solo customerId evita duplicación, pero aumenta coordinación de lectura.
La elección depende de:
Una query shape agrupa operaciones con la misma estructura lógica, aunque los valores cambien.
Estas consultas comparten shape:
{ businessId: A, status: 'pending' }
{ businessId: B, status: 'completed' }El planner y plan cache trabajan alrededor de shapes y planes. Por eso conviene evaluar la estructura, no una sola ejecución con un valor fácil.
Un tenant pequeño y uno outlier pueden producir distribuciones muy diferentes aun con la misma shape.
No todas las queries merecen un índice dedicado.
Una rare query puede aceptar más latencia, ejecutarse en un sistema analítico o utilizar un proceso batch. Crear índices para cada consulta rara aumenta escritura, memoria y almacenamiento.
Los writes también deben documentarse como access patterns.
Ejemplo:
Comando: cambiar estado pending → confirmed
Precondition: estado actual pending
Cambios: status, confirmedAt, version
Concurrencia: impedir doble confirmación
Resultado: modifiedCount 1 o conflictoUpdate:
const result = await db.orders.updateOne(
{
_id: orderId,
status: 'pending',
version: expectedVersion
},
{
$set: {
status: 'confirmed',
confirmedAt: new Date()
},
$inc: { version: 1 }
}
);
if (result.modifiedCount !== 1) {
throw new Error('Order changed or is no longer pending');
}El filtro funciona como precondition y control optimista de concurrencia. Leer primero y actualizar después sin condición dejaría una ventana de carrera.
Un access pattern analítico debe registrar stages y cardinalidad esperada.
Ejemplo: ventas diarias por método de pago.
$match por tenant y rango de fecha
↓
$group por día y paymentMethod
↓
$sort cronológicoEl índice puede ayudar al $match, pero $group sigue consumiendo recursos. Si la consulta es muy frecuente, podría utilizarse computed pattern o una colección derivada, con una estrategia explícita de actualización.
La elección de paginación también es parte del access pattern.
Es sencilla para páginas pequeñas, pero el coste crece al avanzar porque MongoDB debe saltar resultados.
Utiliza los últimos valores del sort:
{
$or: [
{ createdAt: { $lt: lastCreatedAt } },
{
createdAt: lastCreatedAt,
_id: { $lt: lastId }
}
]
}Debe coincidir con un orden estable y un índice compatible.
La API debe devolver una lista vacía, no asumir que siempre existe al menos un documento. El empty state es parte del caso de uso.
La query debe decidir si missing y null son válidos. Un schema en migración puede requerir filtros temporales o defaults de lectura.
El promedio global oculta hotspots, índices grandes y shard key deficiente. Analiza percentiles y outliers.
Paginar solo por createdAt puede producir duplicados o saltos si varios documentos comparten fecha. Añade tie-breaker único.
Insertar o actualizar documentos entre páginas puede alterar el conjunto. La aplicación debe decidir si necesita snapshot consistency o acepta una vista cambiante.
Produce documentos centrados en nombres del dominio, pero no necesariamente en lo que la aplicación hace.
Un documento central demasiado grande puede volver cada actualización un hotspot.
Los índices deben servir query shapes completas. Índices aislados no sustituyen un compuesto bien diseñado.
Forzar el schema operacional a resolver cualquier reporte puede perjudicar el hot path.
Devolver documentos completos aumenta payload y puede exponer campos internos o sensibles.
Una query con 100 documentos no demuestra que funcionará con millones, skew de tenants y working set real.
explain('executionStats').nReturned, keys, docs, sort, tiempo y memoria.Los access patterns conectan requisitos con persistencia. Un buen diseño explica para cada operación qué lee, qué modifica, cuánto crece, qué garantiza y qué cuesta. MongoDB permite modelar documentos alrededor de esas operaciones, pero obliga a hacer explícitos los trade-offs.
Embedding.