Las últimas semanas le he estado dando vueltas al funcionamiento de las operaciones y la concurrencia. ¿Qué nos garantiza que una operación crítica no rompa el sistema?

Fundamentos de Transacciones

Nada. No existe una configuración correcta para todos los casos. Lo que sí existe es entender cómo se comportan los estados de las transacciones cuando funcionan en conjunto. Una transacción es un contrato de consistencia. Cuando no entendemos qué ocurre en los niveles de abajo, dejamos la integridad del sistema a la suerte.

Esto se vuelve evidente cuando nos toca trabajar en servicios financieros, criptomonedas, gestión de inventario, reservas o sistemas distribuidos.

Transacciones ACID

Cuando las bases de datos comenzaron a usarse en sistemas críticos, las fallas dejaban datos en estados inconsistentes, generando errores costosos. En los años 80, Jim Gray junto a otros investigadores definió las propiedades ACID: Atomicidad, Consistencia, Aislamiento y Durabilidad. Cuatro reglas que garantizan que, incluso ante fallos, los datos se mantengan correctos.

Atomicidad

Es la idea del “todo o nada”. Una transacción puede tener 10 pasos, pero si el paso 9 falla, los otros 8 se deshacen como si nunca hubieran existido. Esto se logra mediante Logs (Write-Ahead Logging). La base de datos anota lo que va a hacer antes de tocar los datos reales. Si hay un error, usa ese log para aplicar un Rollback y volver al estado inicial.

Consistencia

Garantiza que una transacción solo lleve a la base de datos de un estado valido a otro. El centro de esta propiedad es asegurar las reglas del negocio. Las herramientas que aparecen son los Triggers, Foreign Keys, Check Constraints y tipos de datos. Por ejemplo. Si intentas poner un volumen negativo y hay una regla que lo prohíbe, la transacción rebota.

Aislamiento

Aquí es donde la cosa se pone interesante. Cuando varias transacciones intentan acceder y modificar el mismo recurso al mismo tiempo, no pueden simplemente ejecutarse en paralelo sin coordinación. Si lo hicieran, terminaríamos con estados inconsistentes. Por eso, una transacción debe esperar su turno mientras otra termina su operación sobre ese mismo dato.

La concurrencia ocurre cuando la ejecución de dos o más fragmentos de código actúa como si se ejecutaran al mismo tiempo.

Para lidiar con la concurrencia, la coordinación se logra con primitivas de exclusión mutua. A bajo nivel hablamos de mutex: mecanismos que garantizan que solo un hilo o proceso acceda a un recurso crítico a la vez (si quieres saber más). En bases de datos, el concepto se traduce en locks, que aplican esa exclusión sobre filas, páginas o tablas. No es cooperación opcional; el motor impone estas reglas para proteger la integridad.

Ahora bien, ¿cuándo y cómo se aplican estos locks? Ahí es donde entran los niveles de aislamiento: configuraciones que definen qué tan estricta será la base de datos al momento de aplicar locks entre transacciones concurrentes. Cada nivel hace diferentes trade-offs entre consistencia y rendimiento:

Durabilidad

Es la promesa de que, una vez que el sistema te dice “OK, guardado”, esa información no se perderá ni aunque se vaya la luz o el servidor explote justo después.

Los cambios se escriben en memoria no volátil (disco duro/SSD) y se confirman en el log de transacciones. Incluso tras un fallo catastrófico, al reiniciar, la base de datos lee el log y termina de aplicar lo que quedó pendiente.

Más allá de ACID

Hoy en día, estos conceptos son la fundación de las bases de datos relacionales. Sin embargo, entender esto es solo el primer paso. Cuando das el salto a arquitecturas modernas con microservicios y bases de datos NoSQL, el motor ya no puede garantizar ACID en todo el sistema, porque tus datos ahora viven en servidores separados y las reglas del juego cambian.

Al distribuir la información, la rigidez de ACID a menudo se cambia por un enfoque más flexible que prioriza que el sistema nunca se caiga. A este nuevo paradigma lo llamamos BASE:

Pasar de ACID a BASE significa aceptar que tu sistema vivirá con cierta inconsistencia temporal a cambio de ser increíblemente rápido y resistente a caídas masivas. En este punto la integridad de los datos deja de venir desde la configuración del motor y se convierte en patrones de diseño que debes implementar en el código (como el patrón Saga o el Two-Phase Commit) para atar los cabos sueltos.

Pero esa… es una historia para otro post.