MongoDB
Explica cómo modelar datos en MongoDB alrededor de documentos, aggregates, límites de crecimiento, atomicidad y patrones reales de lectura y escritura.
El modelo documental organiza información alrededor de . Cada documento puede contener campos, subdocumentos y arrays, y funciona como una frontera importante de lectura, escritura, atomicidad y crecimiento.
dominio
↓
access patterns
↓
aggregate o unidad coherente
↓
document boundary
↓
schema, queries e índicesUn documento no es simplemente una fila con otra sintaxis ni cualquier objeto que exista en el backend. Es una decisión persistente: define qué información viaja junta, qué puede cambiar atómicamente y cuánto trabajo concentra una operación.
Los sistemas manejan conceptos relacionados: una orden tiene items, una reserva tiene participantes, un perfil tiene preferencias. Separar cada pieza en una colección puede obligar a reconstruir continuamente unidades que el negocio trata como un todo.
El modelo documental permite representar esa unidad directamente:
{
_id: ObjectId('...'),
businessId: ObjectId('...'),
customer: {
id: ObjectId('...'),
name: 'Laura Gómez'
},
items: [
{
productId: ObjectId('...'),
name: 'Café molido',
quantity: 2,
unitPrice: Decimal128('18900.00')
}
],
status: 'pending',
total: Decimal128('37800.00'),
createdAt: ISODate('2026-07-24T12:00:00Z')
}La orden puede leerse como una unidad y conserva snapshots históricos. El producto y el cliente siguen existiendo de manera independiente cuando el dominio lo necesita.
MongoDB devuelve documentos. Embeber datos que se leen juntos puede reducir composición, pero un documento enorme también puede aumentar payload y presión de cache.
Los operadores modifican campos dentro del documento. La forma elegida determina si un cambio requiere una operación local o coordinación entre documentos.
Una escritura individual sobre un documento es atómica. Esto permite cambiar varios campos o elementos de un array sin observar un estado intermedio.
Todo lo embebido contribuye al tamaño, frecuencia de actualización e índices del documento. Un array ilimitado convierte una decisión cómoda inicial en un problema operativo.
Muchas escrituras sobre el mismo documento compiten sobre una unidad común. Un contador global o una lista histórica completa dentro de un solo documento pueden crear hotspots.
Una fila relacional representa un tuple dentro de una tabla. Las relaciones se mantienen en otras tablas y se combinan mediante joins.
Un documento puede representar un aggregate completo:
Relacional
orders + order_items + address + joins
Documental
order { items[], deliveryAddress, totals }Esto no significa que MongoDB deba guardar todo junto. Significa que permite alinear la persistencia con unidades de acceso y cambio.
Un objeto de TypeScript puede contener:
Persistirlo directamente mezcla responsabilidades.
class Order {
constructor(
readonly id: string,
private items: OrderItem[]
) {}
calculateTotal(): number {
return this.items.reduce((sum, item) => sum + item.total, 0);
}
}MongoDB no almacena la clase ni su método. La aplicación debe mapear el modelo a un documento persistible:
type OrderDocument = {
_id: ObjectId;
businessId: ObjectId;
items: Array<{
productId: ObjectId;
quantity: number;
unitPriceInCents: number;
}>;
totalInCents: number;
status: 'draft' | 'confirmed';
createdAt: Date;
};El tipo persistido tampoco debería ser automáticamente el input HTTP o la respuesta pública.
Aunque MongoDB permita documentos con formas diferentes, toda colección desarrolla un schema real.
Existe en convenciones, código y documentos actuales. Si no se gobierna, aparece schema drift:
{ total: 10000 }
{ total: '10000' }
{ amount: Decimal128('10000.00') }Se documentan campos, tipos, versiones, defaults y reglas. Puede protegerse mediante JSON Schema validator y runtime validation.
La flexibilidad permite evolución gradual, pero no elimina la necesidad de coherencia.
Un aggregate es una unidad que mantiene invariantes internas y tiene una raíz responsable.
Ejemplo de orden:
order
├── items
├── totals
├── payment summary
└── delivery snapshotLa orden gobierna sus items. Un item no cambia de orden por sí solo ni tiene lifecycle independiente.
En cambio, el producto tiene su propio aggregate:
product
├── current price
├── stock
└── catalog dataLa relación entre ambos se conserva con productId y snapshots dentro de la orden.
Data locality significa que información relacionada puede encontrarse dentro de la misma unidad lógica. Beneficios posibles:
Costes posibles:
La localidad debe servir access patterns, no convertirse en un objetivo absoluto.
En MongoDB, duplicar puede ser correcto si se conoce la semántica.
{
productId,
productNameAtPurchase: 'Café molido',
unitPriceAtPurchase: Decimal128('18900.00')
}No se actualiza cuando cambia el producto.
{
authorId,
authorDisplayName: 'Nicolás'
}Debe existir una estrategia para propagar cambios y reconciliar fallos.
{
commentCount: 12840
}Evita contar continuamente, pero requiere actualización confiable.
Redundancia sin source of truth ni política produce inconsistencia accidental.
Una colección puede contener variantes relacionadas:
{
type: 'physical',
weightGrams: 500
}
{
type: 'digital',
downloadUrl: '...'
}Esto puede ser adecuado cuando comparten access patterns e identidad conceptual. Debe existir un discriminador claro y validation por variante.
Mezclar documentos solo porque “MongoDB lo permite” dificulta queries, índices y mantenimiento.
Además de lecturas, el documento debe servir invariantes de escritura.
Ejemplo: confirmar una orden solo una vez.
const result = await db.orders.updateOne(
{
_id: orderId,
status: 'draft'
},
{
$set: {
status: 'confirmed',
confirmedAt: new Date()
}
}
);
if (result.modifiedCount !== 1) {
throw new Error('Order is no longer draft');
}La precondition vive en el filtro. El boundary permite cambiar estado y fecha atómicamente.
Si el mismo comando debe modificar inventario en varios documentos, debe evaluarse una transacción, reserva previa, event-driven workflow o rediseño.
Un array es útil cuando representa una colección acotada dentro del aggregate.
Buenas preguntas:
Un historial completo, seguidores o eventos ilimitados normalmente necesitan otra colección, buckets o subset pattern.
En SaaS, muchos documentos incluyen businessId o tenantId:
{
_id: ObjectId('...'),
businessId: ObjectId('...'),
sku: 'CAF-001'
}Este campo ayuda a:
Toda query sensible debe incluir el scope autorizado. _id por sí solo no demuestra pertenencia.
Los documentos existentes no cambian automáticamente cuando el código añade un campo.
Estrategia compatible:
// versión antigua
{ schemaVersion: 1, name: 'Café' }
// versión nueva
{
schemaVersion: 2,
name: 'Café',
status: 'active'
}Durante la transición, los lectores deben tolerar ambas formas. Después puede ejecutarse backfill y endurecer validation.
Una query puede devolver null. El caso de uso debe distinguir entre no encontrado, no autorizado e inconsistencia.
Puede representar documento antiguo, dato opcional o corrupción. Define defaults y migraciones explícitos.
Un string donde se esperaba número puede romper sort y aggregation. Validation y observabilidad ayudan a detectarlo.
No esperes al error de 16 MiB. Monitorea tamaño y crecimiento antes.
Un cliente muy grande puede romper supuestos basados en promedios. Considera outlier pattern o distribución distinta.
Evita read-modify-replace sin versionado. Utiliza operadores atómicos y preconditions.
Produce un modelo fragmentado con joins constantes y desaprovecha document boundaries.
Persiste campos internos, mezcla DTOs y puede introducir tipos inconsistentes.
Crea documentos gigantes, hotspots y lifecycle confuso.
Los duplicados divergen sin saber cuál es correcto.
El documento debe evaluarse durante años de crecimiento y cambios concurrentes.
La falta de validation no vuelve correctos los documentos; solo permite que la inconsistencia llegue más lejos.
El documento es una unidad de diseño, no un contenedor arbitrario. Un buen boundary alinea dominio, acceso, atomicidad y crecimiento. MongoDB ofrece libertad para formar esa unidad; el equipo asume la responsabilidad de justificarla y mantenerla.
businessId en un sistema multi-tenant?Patrones de acceso.