¿Qué son las transacciones ACID?

Una transacción ACID es un grupo de operaciones de base de datos que hace commit como una sola unidad — atómica, consistente, aislada y durable. La idea es anterior al acrónimo: Jim Gray definió las garantías en 1981, Härder y Reuter las bautizaron ACID en 1983, y cuarenta años después sigue siendo el contrato que permite mover dinero en software sin, de vez en cuando, inventar o destruir una parte.

Puntos clave

Cómo funcionan las transacciones ACID en SQL (ejemplo de transferencia bancaria)

BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 'alice';
UPDATE accounts SET balance = balance + 100 WHERE id = 'bob';

-- ¿Caída o error entre los dos updates? El motor hace rollback:
-- ROLLBACK;  →  ambos cambios desaparecen; el dinero no puede evaporarse

COMMIT;       -- o ambos se vuelven permanentes, de forma atómica y durable

El código de aplicación encuentra las mismas garantías en paquetes más pequeños — operaciones atómicas de campo que terminan la carrera de read-modify-write, y lotes que hacen commit juntos:

// JavaScript / Node.js — Back4app JS SDK
// Atomicity where apps actually need it
counter.increment('sold', 1);        // atomic single-field update — no
await counter.save();                // read-modify-write race possible

// All-or-nothing batch: both rows commit, or neither does
await Parse.Object.saveAll([debitEntry, creditEntry], { transaction: true });

// Flutter / Dart — Back4app Flutter SDK
// Atomicity where apps actually need it
counter.setIncrement('sold', 1);     // atomic single-field update — no
await counter.save();                // read-modify-write race possible

// Batches group writes; atomic counters remove the classic race
await ParseObject.saveAll([debitEntry, creditEntry]);

// iOS / Swift — Back4app Swift SDK
// Atomicity where apps actually need it
var updated = counter
updated.sold = (updated.sold ?? 0) + 1
// Prefer the atomic operation over read-modify-write:
let op = counter.operation.increment("sold", by: 1)
op.save { result in
  if case .success = result { print("atomic increment committed") }
}

// Android / Kotlin — Back4app Android SDK
// Atomicity where apps actually need it
counter.increment("sold")            // atomic single-field update — no
counter.saveInBackground()           // read-modify-write race possible

// Batches group writes; atomic counters remove the classic race
ParseObject.saveAllInBackground(listOf(debitEntry, creditEntry))

El ciclo de vida de la transacción: BEGIN, COMMIT y ROLLBACK

Las cuatro propiedades, cada una por lo que se rompe sin ella: atomicidad — sin ella, escrituras parciales (la transferencia debitada-pero-nunca-acreditada). Consistencia — sin ella, estados commiteados que violan tus propias reglas (stock negativo, referencias huérfanas). Aislamiento — sin él, las transacciones concurrentes leen el trabajo a medio hacer de las demás. Durabilidad — sin ella, datos “commiteados” que una caída deshace en silencio. Bajo el capó, tres mecanismos las entregan: logs de undo para el rollback, write-ahead logging para sobrevivir a las caídas, y locks o MVCC para la concurrencia.

Niveles de aislamiento vs. anomalías de lectura

La matriz que casi ningún resultado de búsqueda arma — qué nivel detiene qué anomalía:

Traduciendo: un dirty read ve trabajo sin commit; un non-repeatable read recibe respuestas distintas al preguntar dos veces; un phantom ve filas aparecer a mitad de la transacción. La mayoría de los motores modernos usa por defecto comportamiento de snapshot basado en MVCC — cada transacción lee un snapshot consistente mientras los escritores avanzan — y por eso “los lectores no bloquean a los escritores” se volvió la norma, no la excepción.

ACID vs. BASE — y el homónimo de la consistencia

Una desambiguación carga toda esta comparación: la C de ACID y la C de CAP son palabras distintas vistiendo la misma letra. Consistencia en ACID significa que cada transacción preserva las reglas que declaraste. Consistencia en CAP significa que todos los nodos concuerdan ahora mismo. Una base de datos de un solo nodo es totalmente ACID sin que CAP entre a la sala; un sistema distribuido elige su trade-off de CAP y sus garantías transaccionales por separado.

Quién garantiza qué

Las transacciones distribuidas merecen su nota al pie honesta: el commit en dos fases (two-phase commit) compra atomicidad entre nodos al precio de latencia y de un coordinador bloqueante, razón por la que las arquitecturas de microservicios prefieren cada vez más las sagas — secuencias de transacciones locales con rollbacks compensatorios, cambiando consistencia inmediata por disponibilidad. Si un workflow genuinamente no tolera compensación, eso es evidencia de que pertenece a una sola base de datos, no a varias.

Casos de uso comunes

• Movimiento de dinero. Transferencias, pagos, libros contables — el caso canónico y todavía el más claro.
• Inventario y reservas. Decrementar el stock y confirmar el pedido juntos, o mirar a dos clientes comprar el último asiento.
• Invariantes de varias filas. Pedido + líneas de detalle, cuenta + registro de auditoría — registros que solo nacen válidos juntos.
• Contadores bien hechos. Incrementos atómicos — la dosis útil más pequeña de ACID — terminan la carrera de read-modify-write sin transacciones completas.
• El complemento de consistencia eventual. Feeds, likes, analytics: enrutados explícitamente lejos del costo transaccional, a propósito.

¿Debe ser ACID? Matriz de decisión

El oficio es enrutar por escritura: el checkout usa transacciones, el contador de vistas usa un incremento atómico, el feed tolera un segundo de deriva — una aplicación, tres niveles de precio para la consistencia.

Limitaciones y trade-offs

• La coordinación es el centro de costos. Los locks compiten, los syncs del WAL golpean el disco, los reintentos de serializable abortan — la corrección tiene una factura de throughput, y esa es la razón entera de que BASE exista.
• Los niveles de aislamiento son un default traicionero. La mayoría de los motores no usa serializable por defecto; conoce tu nivel, o las anomalías que creías imposibles son apenas improbables.
• Las transacciones largas son mala señal. Sostener locks durante el tiempo de decisión del usuario o llamadas de red convierte garantías en contención; mantén las transacciones cortas y decididas.
• El ACID distribuido es caro por naturaleza. Rondas de consenso por cada commit — págalo donde las invariantes lo exijan, no en todas partes por reflejo.
• ACID no puede validar tus reglas por ti. La consistencia preserva constraints declarados; las reglas de negocio nunca codificadas quedan fielmente sin aplicar.

Transacciones ACID en Back4app

Back4app es una plataforma open-source de Backend as a Service (BaaS) que combina base de datos gestionada, APIs REST y GraphQL generadas automáticamente, autenticación, almacenamiento de archivos y funciones serverless con Cloud Code. Su kit transaccional coincide con cómo las apps realmente consumen ACID: cada escritura de objeto único es atómica en el motor de documentos subyacente, los incrementos atómicos y las operaciones de array terminan las clásicas carreras de contadores (las pestañas de código de arriba), los guardados en lote agrupan escrituras, y las invariantes de varios pasos pertenecen a Cloud Code — validadas y ejecutadas en el servidor, donde un trigger beforeSave puede rechazar cualquier escritura que rompería las reglas. La matriz de decisión viene incorporada: atomicidad barata por defecto, coordinación completa donde la pidas.