Explica transacciones multi-documento en replica sets y sharded clusters, sessions, retries, límites, aislamiento y costos frente al modelado documental.
Las transacciones permiten que varias operaciones sobre documentos o colecciones se confirmen o aborten como una unidad. Son útiles cuando una invariantes legítima cruza el límite natural de un documento, pero añaden coordinación, retención de recursos, retries y complejidad operacional.
Texto
session
→ start transaction
→ reads y writes
→ commit
o
→ abort
MongoDB no necesita una transacción para una sola escritura de documento: esa operación ya es atómica.
crear una orden y reservar inventario en documentos separados;
mover una relación entre dos aggregates;
escribir estado y outbox de forma conjunta;
mantener una invariantes unique que depende de varios documentos.
Antes pregunta si los datos que siempre cambian juntos podrían vivir de forma acotada en un documento. No embeber arrays ilimitados únicamente para evitar transacciones.
Una transacción lee desde una vista coherente compatible. No significa que otros writers estén bloqueados hasta finalizar. Si existe un conflicto, MongoDB puede abortar una de las transacciones.
El callback debe tolerar reejecución completa ante errores transitorios.
El commit pudo haberse aplicado, pero el cliente no recibió confirmación. Debe reintentarse el commit según el driver, no ejecutar nuevamente todo el workflow de forma arbitraria.
Utiliza withTransaction o la API recomendada por el driver porque implementa parte de este protocolo. Aun así, comprende qué operaciones externas quedan fuera.
Aunque los límites concretos evolucionan por versión, una transacción no debe convertirse en un contenedor de trabajo masivo. Documentos grandes, muchos índices y operaciones cross-shard elevan coste.
Las transacciones distribuidas pueden coordinar varios shards. Son más costosas que una transacción localizada. Incluir shard key en filtros y diseñar colocación por tenant reduce fan-out.
Confirma versión, FCV y compatibilidad del driver.
Dos transacciones pueden modificar el mismo documento. Una puede abortar con error transitorio. El retry debe volver a leer el estado; no reutilices resultados externos obsoletos.
Las transacciones coordinan invariantes multi-documento, no sustituyen buen modelado. Deben ser cortas, reintentables y libres de efectos externos. El commit puede ser ambiguo, los callbacks pueden repetirse y cada operación debe participar explícitamente mediante la misma session.
Comprueba lo aprendido
¿Cuándo no necesitas una transacción?
¿Qué diferencia existe entre transient error y unknown commit result?