ACID

Una transacción puede ejecutarse a medias si el sistema falla a mitad de camino. Dos transacciones pueden entrar en conflicto al modificar los mismos datos. Una base de datos transaccional sin garantías no es confiable para aplicaciones reales. ACID resuelve eso.

Tres conceptos que necesitás tener claros

Qué ocurre cuando una transacción falla a mitad de camino

Una transacción es una unidad de trabajo con uno o más pasos. Caso clásico: transferir dinero de la cuenta A a la cuenta B.

UPDATE cuentas SET saldo = saldo - 100 WHERE id = 'A';
-- ¿qué pasa si el servidor se cae justo ACÁ?
UPDATE cuentas SET saldo = saldo + 100 WHERE id = 'B';

Si el sistema falla después del primer UPDATE pero antes del segundo, el dinero desaparece. La base de datos queda en un estado inconsistente.

ACID es el conjunto de propiedades que evita este tipo de problemas.

Cómo ACID protege cada aspecto de una transacción

Atomicidad — “todo o nada”

Sin atomicidad, una falla a mitad de camino deja cambios parciales imposibles de deshacer. No hay forma de saber qué operaciones alcanzaron a persistir.

Consistencia — “los datos siempre cumplen las reglas”

La base de datos solo transiciona de un estado válido a otro. Las reglas del esquema (constraints, foreign keys, tipos de dato) se verifican en cada escritura; si algo las viola, la transacción se rechaza. Así nunca quedan precios negativos ni foreign keys huérfanas.

Aislamiento — “las transacciones concurrentes no se interfieren”

El nivel de aislamiento determina qué cambios de otras transacciones concurrentes puede observar una transacción. Sin aislamiento, las modificaciones simultáneas se interfieren y producen resultados incorrectos.

Durabilidad — “una vez confirmado, no se pierde”

Cuando una transacción hace commit, los cambios sobreviven incluso ante un fallo del sistema, como un corte de luz o un crash del servidor.

El mecanismo en acción

❌ Sin transacción: el dinero desaparece

-- Suponer que A tiene $500 y B tiene $0

UPDATE cuentas SET saldo = saldo - 100 WHERE id = 'A';
-- saldo de A ahora: $400

--- FALLA DEL SISTEMA ---

UPDATE cuentas SET saldo = saldo + 100 WHERE id = 'B';
-- NUNCA SE EJECUTA

-- Resultado: A perdió $100, B nunca los recibió

✅ Con transacción: atomicidad protege

BEGIN;

UPDATE cuentas SET saldo = saldo - 100 WHERE id = 'A';
-- saldo de A ahora: $400

--- FALLA DEL SISTEMA ---

-- Al reiniciar, la BD ve que la transacción no hizo COMMIT.
-- Hace ROLLBACK automático.
-- saldo de A vuelve a: $500 (se deshizo el UPDATE)
-- saldo de B sigue: $0

✅ Consistencia: la base de datos rechaza datos inválidos

CREATE TABLE productos (
    id SERIAL PRIMARY KEY,
    precio DECIMAL(10,2) CHECK (precio > 0),
    stock INTEGER CHECK (stock >= 0)
);

BEGIN;
INSERT INTO productos (precio, stock) VALUES (-5, 10);
-- ERROR: CHECK constraint "precio > 0" violated
-- La transacción se rechaza. La BD nunca queda con precios negativos.
COMMIT;

Cuándo conviene ACID pleno y cuándo conviene reducir sus garantías

Casos de uso

La consistencia de ACID no es la consistencia distribuida