Escena Viva ya persiste en MongoDB y los controladores no saben que existe. Ahora toca la parte del trabajo que separa una aplicación que funciona de una aplicación que aguanta: cómo se relacionan los datos entre sí y cómo se consultan cuando las preguntas dejan de ser triviales.

Tomaremos la decisión de modelado más importante del mundo documental —incrustar o referenciar—, veremos cómo funciona populate de verdad y por qué no es un JOIN, mediremos el problema N+1, defenderemos una desnormalización deliberada, construiremos los informes de Escena Viva con el framework de agregación —jubilando los que en el módulo 3 hacíamos leyendo CSV— y aprenderemos a mirar los índices con explain() en vez de suponer.

1. Incrustar frente a referenciar
2. Las decisiones de Escena Viva, justificadas una a una
3. Referencias con ref y populate
4. El problema N+1: medirlo y resolverlo
5. Desnormalización deliberada
6. El framework de agregación como tubería
7. Informes reales de Escena Viva
8. $lookup frente a populate
9. Índices en serio y explain()
10. Índices parciales, coste de escritura, texto y geoespacial

En una base de datos relacional esta decisión no existe: todo se separa en tablas y se une con JOIN. En MongoDB tienes las dos opciones, y elegir mal es la causa número uno de proyectos que "se vuelven lentos sin saber por qué".

Incrustar es meter los datos hijos dentro del documento padre, como nuestras sesiones dentro del Evento. Referenciar es guardarlos en otra colección y almacenar solo su identificador, como Pedido.usuarioId.

El límite de 16 MB por documento no es una recomendación: es un límite duro de BSON. Un documento que crece indefinidamente chocará con él, y el fallo llegará en producción, con datos reales, un día cualquiera. Pero mucho antes ya duele: MongoDB reescribe el documento entero en cada actualización, así que un documento de 2 MB al que añades un elemento pequeño mueve 2 MB de disco y de red. Existe una tercera vía, el patrón de subconjunto: incrustar los pocos hijos que se muestran siempre (las 3 últimas reseñas) y referenciar el resto.

Las sesiones se incrustan en el evento. Cardinalidad acotada: entre 1 y 7 en nuestro catálogo, quizá 60 en una obra en cartel. Tamaño ridículo: cinco campos, unos 150 bytes. Acceso siempre conjunto: GET /eventos/evt-001 devuelve el evento con sus sesiones y la ficha web las muestra todas. No se comparten: una sesión no tiene sentido fuera de su evento. La única objeción seria es la volatilidad —vendidas cambia en cada compra y eso reescribe el documento—, pero como es diminuto el coste es despreciable. Incrustar gana con claridad.

Los pedidos se referencian. Crecimiento sin techo: un festival puede generar 20.000. Dentro del evento, el documento crecería hasta reventar y cada compra reescribiría megabytes. Además se consultan por su cuenta ("mis pedidos", "pedidos de hoy") sin partir del evento, y tienen ciclo de vida propio con cuatro estados.

Las entradas se referencian. Es la entidad de mayor volumen y se acceden por su código en la puerta, individualmente, sin saber el pedido. Tienen su propio ciclo (valida → usada | anulada).

El usuario se referencia desde el pedido. Un usuario tiene N pedidos y no queremos duplicar su nombre y correo en cada uno: si cambia el correo, habría que reescribirlos todos.

Las flechas continuas son datos que viven en el mismo documento; las discontinuas, referencias que exigen una consulta adicional. Esa distinción visual es exactamente la diferencia de coste.

Ya declaramos las referencias: usuarioId: { type: Schema.Types.ObjectId, ref: 'Usuario' }. El ref dice qué modelo hay al otro lado; populate sustituye el identificador por el documento.

Y ahora lo importante, lo que la documentación menciona de pasada y arruina aplicaciones: populate no es un JOIN. MongoDB no une nada. Mongoose ejecuta tu consulta, recoge los identificadores del campo poblado, lanza una segunda consulta (Usuario.find({ _id: { $in: [...] } })) y cose los resultados en memoria, en tu proceso Node. Consecuencias:

• Un populate sobre 50 pedidos son 2 consultas, no 50: Mongoose agrupa los identificadores. Un poblado anidado de dos niveles, 3 consultas.
• El coste de coser lo paga tu bucle de eventos, no el servidor de base de datos.
• No puedes filtrar el padre por un campo del hijo. "Pedidos cuyo usuario sea organizador" no se expresa con populate; la opción match no descarta padres, deja el campo a null y el pedido sigue apareciendo. Para eso, $lookup con $match.

Aparece cuando, para resolver una lista de N elementos, lanzas una consulta por elemento. Es facilísimo de escribir sin darse cuenta:

Con una latencia modesta de 2 ms por consulta, son 202 ms de espera pura y secuencial para una respuesta que debería tardar 5 ms. Y escala con el tráfico: 100 peticiones simultáneas son 10.100 consultas. Medirlo es trivial y deberías hacerlo antes de optimizar nada: mongoose.set('debug', true) imprime cada consulta que se envía al motor.

sesion.vendidas es información redundante: podría calcularse contando entradas válidas. La guardamos igualmente, y no por pereza.

A favor: comprobar el aforo antes de vender es la operación más frecuente y más sensible a la latencia de la plataforma, y leer un entero de un documento ya cargado cuesta cero, mientras que contar entradas exige una agregación sobre millones de documentos. El catálogo muestra "quedan 88 entradas" en cada tarjeta: con el contador, el listado sale de una sola lectura. Y permite la actualización atómica condicional que resolverá la sobreventa, porque solo se puede comparar contra un campo que exista en el documento.

El precio, dicho con claridad: hay dos fuentes de verdad para el mismo hecho y pueden divergir. Si se crean entradas sin incrementar el contador, o al revés, o un proceso muere entre ambas operaciones, el catálogo miente. Y ningún mecanismo del motor lo impide: MongoDB no conoce esa relación. Ese precio se paga en tres niveles:

1. Atomicidad del conjunto: que reservar aforo, crear el pedido y emitir entradas ocurra todo o nada. Es la lección 07-06.
2. Conciliación periódica: un trabajo programado que recuenta y corrige dejando traza. La red de seguridad.
3. Una única puerta de escritura: nadie toca vendidas ni crea entradas fuera del repositorio. Si hay diez sitios que tocan el contador, la incoherencia es cuestión de tiempo.

Si el módulo 3 te dejó cómodo con pipeline() y los streams, la agregación te resultará familiar: es una tubería de etapas donde cada una recibe documentos, los transforma y pasa el resultado a la siguiente. La diferencia es que se ejecuta dentro del servidor de base de datos, cerca de los datos, y no en tu proceso.

Dos reglas de oro sobre el orden, porque el rendimiento depende de él. $match lo más pronto posible: es la única etapa que puede usar índices, y solo si va al principio; filtrar al final significa procesar toda la colección. Y $project para descartar campos pesados pronto: menos bytes por la tubería y menos memoria, porque cada etapa tiene un límite de 100 MB (superable con allowDiskUse: true, pero si lo necesitas, replantea la consulta).

En el módulo 3 calculábamos la ocupación leyendo datos/ventas.csv con streams. Aquel fue un ejercicio excelente de tuberías, pero ahora los datos están en la base y el motor los agrega mejor que nosotros.

Con nuestro catálogo semilla (7 sesiones, aforo total 3000, 1811 vendidas), esta tubería devuelve las tres salas ordenadas por recaudación y una ocupación global del 60,4 %.

Y un panel completo en una sola consulta con $facet: cada rama recibe los mismos documentos de entrada y produce su propio array, sustituyendo tres viajes a la base por uno. Es la etapa perfecta para paneles de control.

Criterio práctico: populate para servir documentos a la API; $lookup para informes y cuando necesites filtrar o agregar sobre la relación. Un detalle que despista: en $lookup, from es el nombre real de la colección (usuarios, en plural y minúsculas, tal como lo pluraliza Mongoose desde el modelo Usuario), no el nombre del modelo.

Un índice es un árbol B ordenado por los valores de uno o varios campos, con punteros a los documentos. Sin él, "dame los eventos del Teatro Almendra" obliga a leer todos los documentos: un collection scan o COLLSCAN. Con él, el motor baja por el árbol: un IXSCAN.

En un índice compuesto el orden de los campos manda, como en un listín ordenado por apellido y luego por nombre: sirve para buscar por apellido, y por apellido+nombre, pero no solo por nombre. Es el principio del prefijo, aplicado a esquemaEvento.index({ estado: 1, sala: 1, titulo: 1 }):

La regla nemotécnica es ESR: primero los campos comparados por Equaldad, luego el de Sort y por último los de Rango. Un campo de rango antes del de ordenación obliga al motor a ordenar en memoria, que es justo lo que quieres evitar.

Se lee con dos indicadores. stage: 'COLLSCAN' significa que no hay índice utilizable: en una colección pequeña da igual, en una grande es una alarma. Y la proporción totalDocsExamined / nReturned: lo ideal es 1, examinar exactamente lo que devuelves; si examinas 50.000 para devolver 20, el índice no está haciendo su trabajo aunque exista. Un caso especial excelente: si el índice contiene todos los campos que la consulta necesita (filtro y proyección), MongoDB responde sin tocar los documentos —consulta cubierta— y totalDocsExamined vale 0.

Un índice único normal rechaza duplicados incluyendo los null: si diez entradas tienen codigoExterno: null, el segundo ya viola la unicidad. La solución es el índice parcial, que solo indexa los documentos que cumplen un filtro.

Y el recordatorio incómodo: cada índice se paga en cada escritura. Insertar un documento con seis índices son siete estructuras que actualizar. Ocupa memoria —idealmente los índices caben en RAM— y disco. Un índice que ninguna consulta usa es puro coste, y MongoDB te deja auditarlo con Evento.collection.aggregate([{ $indexStats: {} }]): si accesses.ops sigue a 0 tras semanas en producción, sobra.

Solo puede haber un índice de texto por colección, y para buscadores serios (sinónimos, corrección, relevancia afinada) lo habitual es delegar en un motor especializado como Elasticsearch o Meilisearch, no forzar MongoDB.

• Incrustar algo que crece sin límite. El día que un evento acumule 30.000 pedidos incrustados, superará los 16 MB y no se podrá escribir. No hay parche, hay migración.
• Creer que populate es un JOIN. Son consultas adicionales, y dentro de un bucle se convierten en N+1.
• Filtrar por un campo poblado. populate con match no descarta padres: deja el campo a null. Usa $lookup + $match.
• Poner $match al final de la agregación. Pierdes el índice y procesas toda la colección.
• Olvidar $unwind antes de agrupar por un campo de un array. Sumarías arrays enteros en vez de sus elementos.
• Crear índices "por si acaso". Cada uno ralentiza las escrituras. Créalos desde consultas medidas y audítalos con $indexStats.
• Consejo: explain('executionStats') en cualquier consulta de una ruta caliente, antes de darla por buena.
• Consejo: una agregación con tres $lookup anidados suele ser la señal de que ese subsistema encajaría mejor en un modelo relacional. Buen momento para leer la lección siguiente sin prejuicios.

Escribe una agregación resumenPorOrganizador() que devuelva, para cada organizadorId, el número de eventos publicados, el total de sesiones, las entradas vendidas, la recaudación en céntimos y la ocupación media, ordenado por recaudación descendente.

Este código lista las entradas de una sesión con el nombre del comprador. Indica cuántas consultas lanza para 200 entradas y reescríbelo con una sola.

Escena Viva añade la pantalla "próximas sesiones con entradas de una sala": filtra por estado: 'publicado' y sala, exige sesiones con fechaHora >= ahora y ordena por sesiones.fechaHora ascendente. Propón el índice, justifica el orden con la regla ESR y di qué esperarías ver en explain().

Ejercicio 1.

Ejercicio 2. Lanza 401 consultas: 1 para las entradas, 200 para los pedidos y 200 para los usuarios. Con $lookup se resuelve en una:

Ejercicio 3. Índice: { estado: 1, sala: 1, 'sesiones.fechaHora': 1 }. Por ESR, estado y sala se comparan por igualdad y van primero; sesiones.fechaHora cumple a la vez el papel de ordenación y de rango, y va al final. Al ser un campo de un array de subdocumentos, MongoDB lo trata como índice multiclave. En explain('executionStats') esperaríamos stage: 'IXSCAN', ausencia de una etapa SORT en memoria —la ordenación la sirve el propio índice— y una relación totalDocsExamined / nReturned cercana a 1.

Has aprendido a modelar relaciones en MongoDB con criterio: cuándo incrustar y cuándo referenciar, con la tabla de criterios y las decisiones de Escena Viva justificadas una por una. Sabes qué hace populate de verdad —consultas adicionales cosidas en tu proceso, no un JOIN—, cómo detectar y matar un N+1, y por qué mantenemos vendidas desnormalizado aceptando conscientemente la deuda de coherencia que genera. Has construido con el framework de agregación los informes que en el módulo 3 salían de un CSV: recaudación por sala, ocupación por categoría, ranking de sesiones y ventas por mes, además de un panel completo con $facet. Y ya no supones nada sobre índices: los diseñas con la regla ESR y los verificas con explain().

También has visto los límites. $lookup anidado, integridad referencial que nadie garantiza, una invariante vendidas <= aforo que depende de tu disciplina en vez de del motor. Nada de esto descalifica a MongoDB —es la persistencia oficial de Escena Viva y funciona—, pero deja una pregunta legítima en el aire: ¿cómo sería esto en un sistema relacional?

En la lección siguiente lo respondemos modelando el mismo dominio en PostgreSQL con Sequelize: tablas, claves foráneas, normalización, una restricción CHECK (vendidas <= aforo) que el motor hace cumplir pase lo que pase, include como un JOIN real de una sola consulta, SQL parametrizado frente a la inyección, y una segunda implementación de src/repositorios/eventos.js que demostrará que la arquitectura de la lección 07-01 no era teoría.