MongoDB
Explica la atomicidad por documento en MongoDB, cómo diseñar precondiciones y updates para preservar invariantes sin recurrir siempre a transacciones.
MongoDB garantiza atomicidad a nivel de : una escritura que modifica varios campos de ese documento se observa completa o no se observa. Ningún lector ve un estado intermedio con solo parte de los operadores aplicados.
db.inventory.updateOne(
{
businessId,
productId,
available: { $gte: quantity }
},
{
$inc: {
available: -quantity,
reserved: quantity,
version: 1
},
$set: {
updatedAt: new Date()
}
}
);Stock, reserva, versión y fecha cambian como una unidad dentro de ese documento.
estado anterior
→ operación completa
→ estado posteriorAtomicidad evita que otros clientes observen la mitad del cambio. No garantiza que:
Una update atómica puede incorporar precondiciones:
db.orders.updateOne(
{
_id: orderId,
businessId,
status: 'pending'
},
{
$set: {
status: 'confirmed',
confirmedAt: new Date()
}
}
);Si otra request confirmó primero, el filtro ya no coincide. La aplicación debe comprobar matchedCount y modifiedCount.
Con versión:
db.orders.updateOne(
{
_id: orderId,
version: expectedVersion
},
{
$set: changes,
$inc: { version: 1 }
}
);Esto implementa optimistic concurrency. La atomicidad asegura que comparar versión y modificar ocurren dentro de la misma operación.
Patrón peligroso:
leer stock 10
calcular stock 8
reemplazar documentoDos clientes pueden perder cambios. Mejor:
{ $inc: { stock: -2 } }o incluir una precondición.
Los operadores posicionales también forman parte de la atomicidad del documento:
db.orders.updateOne(
{
_id: orderId,
items: {
$elemMatch: {
productId,
quantity: { $lte: 98 }
}
}
},
{
$inc: {
'items.$.quantity': 2
}
}
);La regla se mantiene dentro de la misma escritura, aunque debes evitar duplicados ambiguos.
db.products.updateMany(
{ businessId, active: true },
{ $set: { needsReview: true } }
);Cada documento se actualiza atómicamente, pero el conjunto completo no es una unidad atómica. Durante la operación otros clientes pueden observar algunos documentos actualizados y otros no. Un fallo puede dejar progreso parcial.
Insertar un documento es atómico respecto a ese documento. Eliminarlo también. Un sequence insert + update de otro documento no es atómico sin transacción o rediseño.
Un unique index implementa una invariantes concurrente:
db.memberships.createIndex(
{ businessId: 1, userId: 1 },
{ unique: true }
);Dos inserts concurrentes no pueden crear la misma identidad lógica. La validación en la aplicación no reemplaza esta garantía.
Una operación de escritura sobre un documento ya tiene atomicidad; envolverla en una transacción no añade valor automáticamente y sí puede añadir complejidad.
Si varios valores siempre se leen y cambian juntos, embedding puede convertir una invariantes multi-documento en una operación atómica local.
Ejemplo correcto:
{
orderId,
items: [/* snapshot */],
subtotal,
tax,
total
}Items y totales pertenecen a la misma orden y pueden actualizarse juntos mientras la orden está en draft.
No debes embeber datos ilimitados solo para obtener atomicidad.
Son necesarias cuando una invariantes legítima cruza documentos o colecciones, por ejemplo transferir saldo entre dos cuentas. Antes de usarlas pregunta:
Una escritura puede confirmarse en el servidor y perderse la respuesta. Atomicidad no elimina esta ambigüedad. Utiliza retryable writes cuando aplica, operation IDs o reconciliación.
Atomicidad describe indivisibilidad. Write concern describe qué confirmación espera el cliente. Una escritura atómica con w: 1 y una con majority tienen distinta tolerancia a failover.
Puede significar valor ya igual o update sin cambio efectivo.
Puede ser not found, tenant incorrecto o conflicto de estado.
No se aplica un documento parcialmente inválido.
La operación falla; no deja una versión parcial.
Sigue siendo atómica sobre el documento, aunque la expression debe manejar tipos y null.
updateMany es globalmente atómico;La principal unidad transaccional natural de MongoDB es el documento. Diseñar buenos boundaries permite expresar invariantes mediante operadores y filtros atómicos. Cuando una regla cruza documentos, evalúa transacción, rediseño o workflow idempotente sin confundir atomicidad con durabilidad o consistencia global.
updateMany globalmente atómico?Concurrencia.