Article

🔐 ACID — las 4 garantías de una transacción

Published June 08, 2026 · 13 hours, 27 minutes ago

Gastón Gaitan
Gastón Gaitan
Backend Engineer · Jun 08, 2026
🔐 ACID — las 4 garantías de una transacción
Transacciones y propiedades ACID
🗄️ Bases de Datos · SQL · Backend

Transacciones y propiedades ACID

Una transacción agrupa varias operaciones SQL como una sola unidad indivisible. Las propiedades ACID son las cuatro garantías que una base de datos relacional ofrece para que esos datos sean confiables incluso ante fallos y accesos concurrentes.

💡 Qué es una transacción

Un grupo de operaciones que se ejecuta entre BEGIN y COMMIT: todo o nada.

🔐 Qué es ACID

Atomicity, Consistency, Isolation y Durability: las 4 garantías de una transacción.

📏 Para qué sirve

Que los datos sigan siendo correctos ante caídas, errores y concurrencia.

Transacción

El bloque BEGIN … COMMIT

Unidad indivisible

Una transacción se confirma con COMMIT o se deshace por completo con ROLLBACK.

transferencia.sql

Transferir $100 de Ana a Beto

Las dos operaciones deben ocurrir juntas o ninguna.

BEGIN;
  UPDATE cuentas SET saldo = saldo - 100 WHERE id = 1;  -- Ana
  UPDATE cuentas SET saldo = saldo + 100 WHERE id = 2;  -- Beto
COMMIT;
-- si algo falla en el medio:  ROLLBACK;

La transferencia que debe ser atómica

$100
ACID

Las 4 garantías, una por una

A · C · I · D
A
Atomicity
Todo o nada
C
Consistency
Siempre estado válido
I
Isolation
No se pisan entre sí
D
Durability
Persiste tras commit
PropiedadQué garantizaEn una frase
AtomicityTodo o nadaO se hacen todas las operaciones, o ninguna
ConsistencyIntegridadNunca queda un estado que viole constraints
IsolationConcurrenciaCada transacción corre como si estuviera sola
DurabilityPersistenciaLo confirmado sobrevive a caídas del sistema
Atomicity

El ejemplo clásico: la transferencia

Todo o nada

¿Qué pasa si el servidor se cae justo entre los dos UPDATE? Acá se ve por qué la atomicidad es crítica.

Con vs sin atomicidad ante una caída

❌ Sin atomicidad

- $100 a Ana ✓
⚡ el servidor se cae
+ $100 a Beto ✗ (nunca pasó)
Resultado: $100 desaparecidos 💸

✅ Con atomicidad

- $100 a Ana ✓
⚡ el servidor se cae
↩ ROLLBACK automático
Resultado: saldos intactos 👍
Clave: como no se llegó al COMMIT, la base deshace el primer UPDATE. Nunca queda “a medias”.
Isolation

El aislamiento tiene niveles

Lo que más preguntan

El aislamiento no es “todo o nada”: hay 4 niveles que equilibran seguridad vs rendimiento. A más aislamiento, menos problemas de concurrencia, pero más bloqueos y menos velocidad.

NivelDirty readNon-repeatable readPhantom read
Read UncommittedPosiblePosiblePosible
Read CommittedNoPosiblePosible
Repeatable ReadNoNoPosible
SerializableNoNoNo
Próximo tema: qué son exactamente dirty read, non-repeatable read y phantom read, con ejemplos de cada uno.
Durability

Sin durabilidad vs con durabilidad

Tras el COMMIT

😱 Sin durabilidad

  • Ves "compra exitosa"
  • Se corta la luz
  • Al volver, la compra no está
  • Los datos vivían solo en memoria

🛡️ Con durabilidad

  • El commit escribe a disco (WAL)
  • Se corta la luz
  • Al volver, la compra sigue ahí
  • Lo confirmado es permanente
Cómo se logra: antes de confirmar, la base escribe los cambios en un write-ahead log (WAL) en disco. Si se cae, al reiniciar reconstruye el estado.

🎯 Resumen

  • Transacción Grupo de operaciones entre BEGIN y COMMIT: o todas, o ninguna.
  • Atomicity Todo o nada: si algo falla, ROLLBACK deshace todo.
  • Consistency La base pasa de un estado válido a otro; respeta constraints.
  • Isolation Las transacciones concurrentes no se interfieren (tiene 4 niveles).
  • Durability Lo confirmado con commit sobrevive a caídas (gracias al WAL).