Llegamos al final del módulo y a la lección que salda la deuda más antigua del curso. Desde el módulo 4, cuando montamos el primer servidor node:http y vendimos la primera entrada, arrastramos un problema que la validación no resolvía, que los errores bien tipados no resolvían y que ni siquiera $inc resolvía del todo: dos personas comprando a la vez la última entrada disponible. Antes de atacarlo, dos piezas que todo proyecto con base de datos necesita y que casi nadie enseña a tiempo: migraciones, para que el esquema tenga historial como lo tiene el código, y semillas, para poblar la base en un comando. Con ellas jubilaremos por fin datos/eventos.json como fuente de verdad.

1. Migraciones: el esquema también es código
2. sequelize-cli y la migración inicial de Escena Viva
3. Migraciones sobre datos existentes, reglas de oro y el caso de MongoDB
4. Semillas: npm run semilla
5. Transacciones, ACID y el escenario de sobreventa
6. Transacciones en Sequelize y niveles de aislamiento
7. Bloqueo pesimista frente a optimista
8. comprarEntradas transaccional y la solución en MongoDB
9. Interbloqueos, reintentos y qué no meter dentro

Tu código tiene historial: cada cambio es un commit, con autor, fecha, motivo y la posibilidad de revertirlo. El esquema de tu base de datos, si lo creaste con sync() o a mano con psql, no tiene nada de eso. Nadie sabe cuándo se añadió aquella columna, ni por qué, ni cómo estaba antes. Y cuando un compañero clona el repositorio, su base de datos no se parece a la tuya. Una migración es un fichero versionado, guardado junto al código, que describe un cambio de esquema en dos direcciones: up lo aplica, down lo deshace. Se ejecutan en orden y la base guarda cuáles ya aplicó. Tres beneficios lo hacen innegociable: reproducibilidad (máquina nueva, base vacía, un comando), revisión (un cambio de esquema pasa por pull request como cualquier otro) y despliegue automatizado (el CI/CD del módulo 11 las ejecuta antes de arrancar la versión nueva).

Se instala con npm install --save-dev sequelize-cli y npx sequelize-cli init crea la estructura estándar: config/ (conexiones), migrations/, seeders/ y models/. El config/config.json generado no nos sirve, porque la configuración vive en src/config/index.js: lo sustituimos por un config/config.js que exporte un objeto con una clave por entorno (desarrollo, pruebas, produccion), cada una con { url: configuracion.postgresUrl, dialect: 'postgres' }. Una migración es un módulo con dos funciones asíncronas que reciben queryInterface —la API para manipular el esquema— y Sequelize para los tipos. Sequelize crea una tabla SequelizeMeta con una fila por migración aplicada: al ejecutar db:migrate compara los ficheros con esa tabla y aplica solo los que faltan, en orden alfabético — por eso los nombres empiezan por marca de tiempo.

queryInterface ofrece createTable/dropTable, addColumn/removeColumn/changeColumn/renameColumn, addIndex y addConstraint (para CHECK, UNIQUE y claves foráneas), bulkInsert/bulkUpdate/bulkDelete para mover datos dentro de la propia migración, y sequelize.query cuando lo anterior no llega.

Los comandos son npx sequelize-cli db:migrate (aplica las pendientes), db:migrate:status (cuáles están aplicadas) y db:migrate:undo (revierte la última). Semanas después, negocio pide clasificar eventos por idioma. La tabla ya tiene datos: no puedes añadir una columna NOT NULL sin más, porque las filas existentes no tendrían valor y el motor rechazaría el cambio. El patrón correcto tiene tres pasos.

Esta secuencia —añadir permisiva, rellenar, endurecer— es la receta universal para columnas obligatorias sobre tablas pobladas. Memorízala, y con ella las reglas de oro:

1. Nunca edites una migración ya aplicada. En tu máquina la editarías y la reejecutarías, pero en producción ya está en SequelizeMeta y no se reejecutará, así que tu cambio nunca llegará allí. Corregir se hace con una migración nueva.
2. Toda migración debe ser reversible. Escribe el down y pruébalo: un down que no funciona es un despliegue del que no se puede volver a las tres de la mañana.
3. Cambios compatibles hacia atrás. En un despliegue sin parada (módulo 11) conviven durante minutos la versión antigua y la nueva contra la misma base. Si tu migración renombra una columna, la antigua se rompe al instante. La técnica se llama expand and contract: añadir la columna nueva nulable mientras el código nuevo escribe en ambas, copiar los datos, desplegar código que solo usa la nueva y, por último, borrar la antigua.
4. Datos y esquema, separados si son grandes, y prueba sobre una copia de producción. Un UPDATE sobre diez millones de filas dentro de una migración bloquea la tabla y deja el despliegue colgado; para eso, un script aparte por lotes. Y los problemas solo aparecen con volumen, nunca en tu base vacía de tres filas.

"MongoDB no tiene esquema, luego no necesita migraciones." Es falso, y es una de las confusiones más caras del sector. La ausencia de esquema en el motor no elimina el esquema: lo traslada a tu código. Si añades idioma con required: true al esquema de Mongoose, los cinco millones de documentos existentes no lo tienen y cualquier save() sobre ellos fallará. Si renombras precio a precioCentimos, los documentos viejos siguen con el nombre antiguo y tus consultas devolverán vacío sin dar ningún error.

Diferencia real: en SQL la migración cambia la estructura y los datos se adaptan; en MongoDB la migración es una transformación de datos. Pero la disciplina —fichero versionado, up/down, registro de aplicadas, revisión en pull request— es idéntica.

Una semilla carga los datos iniciales. Nuestro caso es entrañable: los 3 eventos y las 7 sesiones de datos/eventos.json, el fichero que nos acompaña desde el módulo 3, se convierten en la carga inicial de la base de datos. Deja de ser el almacén y pasa a ser la semilla. Se invoca con npm run semilla y, con --reiniciar, borra antes de cargar (semilla:limpia).

La idempotencia separa una semilla profesional de un script de usar y tirar: se consigue con upsert sobre la clave de negocio, nunca con insert. Puedes ejecutarla en cada arranque de desarrollo, tras cada migración y antes de cada demo sin miedo a duplicar nada. Y su valor va más allá del desarrollo: en el módulo 9, cuando escribamos pruebas, una semilla determinista es lo que permite afirmar "tras vender 2 entradas de ses-001-1, quedan 86", porque el estado de partida es conocido y reproducible. Combinada con una base de datos en memoria o efímera por suite, hace que las pruebas de integración sean rápidas y aisladas. Lo desarrollaremos allí; aquí basta con dejar la herramienta lista.

Una transacción es un conjunto de operaciones que el motor trata como una sola. Aplicado a alguien que compra dos entradas: atomicidad significa que reservar aforo, crear el pedido y emitir dos entradas ocurre todo o nada, sin estados intermedios visibles —si falla la segunda entrada, el aforo vuelve solo y el pedido no existe—; consistencia, que al confirmar siguen cumpliéndose todas las restricciones (la CHECK (vendidas <= aforo), las claves foráneas, los NOT NULL) y que si el resultado violara alguna el motor revierte todo; aislamiento, que mientras tu transacción está en curso otra no ve tus cambios a medias; y durabilidad, que cuando el motor dice "confirmado" está en disco y un corte de luz un milisegundo después no lo deshace. Sin transacciones, cada operación es atómica por separado, pero el conjunto no lo es: ese es exactamente el problema anotado en mayúsculas dentro de crearPedido en la lección 07-03. Veámoslo: ses-001-1 tiene aforo 400 y 399 vendidas, queda una entrada, y Lucía y Marc pulsan "comprar" en el mismo segundo.

Analicemos por qué fallan las defensas que ya tenemos. La comprobación previa no basta: entre el paso 2 y el paso 4 hay una ventana, y el estado que Marc leyó ya no es el real cuando escribe. Cualquier lógica del tipo "leo, decido, escribo" tiene esa ventana, y en Node es especialmente fácil de abrir, porque cada await cede el control al bucle de eventos, que atiende a Marc justo en ese hueco. Hacer la ventana más pequeña no la elimina: solo hace el fallo más raro y más difícil de reproducir, que es peor. $inc tampoco basta: resuelve la pérdida de actualizaciones —si ambos suman 1, el resultado es 401 y no 400, porque cada suma se aplica sobre el valor real—, pero suma incondicionalmente, sin saber que 401 supera el aforo; hemos cambiado un dato incorrecto por un dato correcto que denuncia una sobreventa ya cometida. Y la validación del esquema tampoco: el validador de Mongoose se ejecuta al guardar un documento completo, y en un updateOne con $inc no tiene acceso al resultado ni al aforo; aunque lo tuviera, se ejecuta en tu proceso, así que dos procesos Node validarían por su cuenta y ambos aprobarían.

La solución debe cumplir una condición: la comprobación y la escritura han de ser una sola operación indivisible para el motor, y hay dos formas de conseguirlo.

Usa la gestionada por defecto; la no gestionada, solo si necesitas puntos de guardado o lógica condicional compleja. El detalle que se olvida siempre: hay que propagar { transaction: t } a cada una de las consultas. Una consulta sin t se ejecuta fuera de la transacción, en otra conexión, y no verá los cambios pendientes ni se revertirá con ellos. Es el bug más común y el más silencioso: todo parece funcionar hasta que algo falla y descubres datos a medias.

El aislamiento perfecto sería ejecutar las transacciones de una en una, pero eso destruiría el rendimiento. Los niveles permiten elegir cuánta corrección pagas en concurrencia.

Las tres anomalías con nuestro ejemplo. Lectura sucia: lees vendidas = 400 de una transacción que aún no ha confirmado y que acabará revirtiéndose; decides sobre un dato que nunca existió. Lectura no repetible: lees 399, otra transacción confirma, vuelves a leer y ahora vale 400 — dos lecturas del mismo dato en la misma transacción dan resultados distintos, y es la anomalía que causa nuestra sobreventa. Lectura fantasma: cuentas 5 entradas, otra transacción inserta una y al recontar hay 6. Con { isolationLevel: Transaction.ISOLATION_LEVELS.SERIALIZABLE } PostgreSQL detecta el conflicto y aborta una de las dos transacciones con un error de serialización: es correcto, pero traslada el trabajo a tu código, que debe reintentar. Para la venta de entradas hay una solución más simple y barata.

Pesimista: asumo que habrá conflicto y bloqueo la fila antes de tocarla. SELECT ... FOR UPDATE la reserva, y cualquier otra transacción que quiera bloquearla espera hasta que yo confirme o revierta.

En Sequelize se pide con lock: t.LOCK.UPDATE. Cuando Marc despierta, lee el valor actualizado, 400, comprueba que no quedan libres y falla limpiamente con un 409 AFORO_INSUFICIENTE. La ventana ha desaparecido. Optimista: asumo que el conflicto es raro, no bloqueo nada, y detecto al escribir si alguien se adelantó, mediante una columna version que se incrementa en cada cambio; el UPDATE lleva la versión leída en el where, y si no afecta a ninguna fila es que otro se adelantó y hay que reintentar desde cero.

Cuál encaja en la venta de entradas. El pesimista, sin duda. La venta tiene un patrón muy característico: cuando salen las entradas de un concierto esperado, miles de personas compiten por la misma fila durante pocos minutos. Con bloqueo optimista la mayoría de intentos fallarían y reintentarían, generando más carga justo en el peor momento y una experiencia pésima. Con bloqueo pesimista las peticiones se serializan sobre esa fila y cada una obtiene respuesta definitiva a la primera: o tienes entrada, o no queda. Además la transacción es cortísima, así que la contención dura milisegundos. El optimista sería la elección correcta para editar la ficha de un evento, donde dos organizadores coinciden una vez al mes.

La versión definitiva. Compárala con la de la lección 07-03, comentario en mayúsculas incluido.

Vuelve al escenario de Lucía y Marc con este código. Lucía entra, bloquea la fila, ve 1 libre, vende y confirma. Marc estaba esperando en el paso 1; despierta, lee vendidas = 400, ve 0 libres y recibe un 409 AFORO_INSUFICIENTE limpio, con su código de error y su mensaje. No hay sobreventa. No hay estado a medias. No hay una entrada emitida sin pedido ni un pedido sin entradas. El problema que abrimos en el módulo 4 está cerrado. En MongoDB se resuelve sin transacción, aprovechando que una actualización de un solo documento sí es atómica: la clave es meter la condición dentro del filtro.

Por qué funciona: el filtro vendidas <= aforo - cantidad y el $inc se evalúan y aplican bajo el bloqueo de documento del propio motor. Si Marc llega después de Lucía, su filtro no casa y findOneAndUpdate devuelve null sin escribir. Es una operación de comparar-e-intercambiar, la misma idea que un compare-and-swap de programación concurrente: rápida, sin transacción y sin requisitos de infraestructura. Su límite: solo cubre un documento, y el pedido y las entradas viven en otras colecciones. Para eso están las sesiones multidocumento, que se abren con mongoose.startSession() y se usan con sesionMongo.withTransaction(async () => { ... }) —que confirma al terminar, revierte si lanza y además reintenta los errores transitorios—, propagando { session } a todas las operaciones, igual que { transaction: t } en Sequelize. Y un requisito operativo que sorprende: las transacciones de MongoDB exigen un conjunto de réplicas; un mongod suelto en tu portátil no las soporta y hay que arrancarlo con --replSet, aunque sea de un solo nodo (en Atlas vienen de serie). Además tienen coste: mantienen instantáneas, caducan a los 60 segundos por defecto y pueden abortar por conflicto de escritura. El criterio: en MongoDB usa la actualización atómica condicional siempre que el problema quepa en un documento —nuestro caso para el aforo, gracias a haber incrustado las sesiones— y reserva las transacciones multidocumento para cuando el cambio abarque varias colecciones de forma innegociable.

Un interbloqueo ocurre cuando dos transacciones se esperan mutuamente: Lucía bloquea la sesión A y quiere la B; Marc bloquea la B y quiere la A. PostgreSQL lo detecta y aborta una con el error 40P01. Se evita bloqueando siempre en el mismo orden (por ejemplo, sesiones ordenadas por identificador ascendente, lo que hace el ciclo imposible), con transacciones cortas y bloqueando lo mínimo. Y cuando aun así ocurra, se reintenta con espera creciente:

Fíjate en el matiz: solo se reintentan errores transitorios. Un AFORO_INSUFICIENTE no se reintenta jamás; no es un fallo temporal, es una respuesta. Y hay cosas que nunca deben entrar en una transacción. Las llamadas HTTP a servicios externos, porque un servicio lento mantiene los bloqueos abiertos durante segundos, el pool se agota y la aplicación entera se para. El envío de correos, por lo mismo y porque además no es reversible: si la transacción revierte, el correo ya salió. Los cobros a la pasarela de pago, que no se deshacen con un ROLLBACK: se cobra antes, o se compensa después. La escritura de ficheros y la emisión de eventos del GestorDeVentas, que no participan en la transacción y harían actuar a los suscriptores sobre datos que quizá se reviertan. Y los bucles largos o cálculos pesados, que alargan la transacción y la contención. La regla: dentro, solo operaciones de base de datos y las mínimas. Todo lo demás va antes (si debe condicionar la compra) o después (si debe reaccionar a ella). En Escena Viva el cobro se autoriza antes, la transacción registra la venta, y el correo de confirmación y el evento venta-registrada se emiten después de confirmar. Cuando ese "después" deba ser fiable —reintentos, orden, entrega garantizada— se convierte en una cola de trabajos, que es lo que veremos con Redis en el módulo 10.

• Editar una migración ya aplicada. No llegará a los entornos que ya la ejecutaron. Corrige con una migración nueva.
• Olvidar { transaction: t } en una consulta, que se ejecuta fuera y no se revierte, o dejar una transacción no gestionada sin rollback en el catch, que retiene una conexión del pool hasta que expire; con suficientes, la aplicación se cuelga.
• Confiar solo en la comprobación previa. Entre leer y escribir hay una ventana, siempre. Bloqueo o filtro atómico.
• Meter una llamada HTTP dentro de la transacción, o reintentar errores de negocio: lo primero agota el pool en el primer pico de tráfico y lo segundo no arregla nada, porque AFORO_INSUFICIENTE no mejora reintentando.
• Creer que MongoDB no necesita migraciones. El esquema existe igual; solo que vive en tu código y en documentos que ya no lo cumplen.
• Consejo: prueba la concurrencia de verdad —50 compras simultáneas contra una sesión con 10 entradas— y mide la duración de tus transacciones: cualquiera que supere los 100 ms merece revisión. Sin esa prueba no sabes si tu solución funciona: crees que funciona.

Implementa anularCompra(pedidoId) con Sequelize de forma transaccional: bloquea el pedido y su sesión, comprueba que el estado permite anular (pagado o emitido), marca las entradas como anuladas, devuelve el aforo y marca el pedido como anulado. Justifica en qué orden bloqueas.

Escribe un script que ponga una sesión de prueba con aforo 10 y vendidas: 0, lance 50 llamadas simultáneas a comprarEntradas de 1 entrada con Promise.allSettled, y verifique que exactamente 10 se resuelven, 40 se rechazan con AFORO_INSUFICIENTE y vendidas acaba valiendo 10.

Ejercicio 1. Se bloquea primero el pedido y después la sesión; mantener siempre ese mismo orden en todas las transacciones que toquen ambas tablas es precisamente lo que hace imposible un interbloqueo.

Ejercicio 2.

Si alguna vez de cada cien ejecuciones da 11 éxitos, tienes una condición de carrera; ejecútalo varias veces, porque los fallos de concurrencia son intermitentes por naturaleza y ese es justamente el motivo por el que hay que buscarlos a propósito.

El módulo 7 se cierra, y con él la etapa del fichero JSON. Empezamos entendiendo por qué datos/eventos.json había dejado de servir y qué aporta un SGBD; modelamos Escena Viva con MongoDB y Mongoose, con sus sesiones incrustadas, sus validadores, sus virtuals y sus índices; escribimos el CRUD completo y jubilamos src/catalogo-datos.js sustituyéndolo por src/repositorios/eventos.js sin que los controladores se enteraran; exploramos relaciones, populate, el problema N+1 y el framework de agregación, que se llevó por delante los informes que hacíamos leyendo CSV; visitamos el mundo relacional con PostgreSQL y Sequelize, donde una CHECK (vendidas <= aforo) convierte una invariante en ley del motor y donde include hace un JOIN de verdad; y hoy hemos versionado el esquema con migraciones, cargado el catálogo con una semilla idempotente —los 3 eventos y las 7 sesiones, aforo 3000, 1811 vendidas— y resuelto, por fin, el problema que arrastrábamos desde el módulo 4.

Porque eso es lo importante: Escena Viva ya no sobrevende. Ni con SELECT ... FOR UPDATE dentro de una transacción en PostgreSQL, ni con findOneAndUpdate y su filtro condicional en MongoDB. Dos motores, dos técnicas, una misma garantía: o la compra ocurre entera, o no ocurre nada. Y sin embargo, hay algo que debería inquietarte. Vuelve a mirar comprarEntradas. Recibe un usuarioId… ¿de dónde? Ahora mismo, de lo que el cliente quiera enviar. Cualquiera puede llamar a la API. Cualquiera puede comprar en nombre de Lucía, consultar los pedidos de Marc, publicar un evento en el Teatro Almendra sin ser su organizador o anular las entradas de un desconocido. No hay usuarios de verdad, no hay contraseñas, no hay sesiones, no hay permisos. El modelo Usuario lleva esperando desde la lección 07-02 con su campo rol —asistente, organizador, administrador— sin que nadie lo use para nada.

En el módulo 8 llenamos ese hueco: autenticación y autorización. Registro de usuarios y hash de contraseñas hecho como es debido, sesiones y cookies con Passport, JSON Web Tokens, control de acceso basado en los roles que ya tenemos modelados, y las buenas prácticas de seguridad que convierten una API que funciona en una API en la que se puede confiar. Los datos ya están a salvo de la concurrencia; toca ponerlos a salvo de los desconocidos.