Atomicidad en las bases de datos: La columna vertebral de las transacciones fiables

La atomicidad es un concepto básico en los sistemas de bases de datos. Significa que una transacción debe tener éxito por completo o no ejecutarse en absoluto. Si algo falla a medio camino, todo se vuelve atrás como si nunca hubiera ocurrido.

¿Por qué es esto tan importante, te preguntarás? Imagina transferir dinero de una cuenta bancaria a otra. Pulsas "Enviar", la aplicación se carga durante un segundo, y entonces algo va mal. El dinero desaparece de tu cuenta, pero nunca llega a la otra. Ahora simplemente... ha desaparecido. Ese escenario es exactamente lo que la atomicidad pretende evitar.

Puede que ya hayas oído hablar del ÁCIDO. Es un conjunto de cuatro propiedades clave que las bases de datos utilizan para garantizar que las cosas no se desmoronen. La atomicidad es la primera de esa lista, y por una buena razón: sin ella, el resto (Coherencia, Aislamiento y Durabilidad) no importan mucho.

En este artículo exploraremos qué significa la atomicidad, cómo funciona y por qué es tan crítica en sistemas cotidianos como la banca y el comercio electrónico. También veremos cómo lo implementan las distintas bases de datos, y cómo puedes diseñar sistemas atómicos que puedan manejar bien las cosas cuando inevitablemente vayan mal.

¿Qué es la atomicidad?

Atomicidad significa que una transacción en una base de datos es indivisible. O se ejecuta hasta el final, con todos y cada uno de los pasos según lo previsto, o no se ejecuta en absoluto. No hay término medio. Nada de actualizaciones a medio terminar, nada de datos parciales guardados, nada de limbos extraños en los que algunas cosas tenían éxito y otras no.

Atomicidad en los SGBD. Fuente: Arpit Bhayani

Si falla una parte de la transacción, se anula toda como si nunca hubiera ocurrido nada. Esto es lo que hace que la atomicidad sea una salvaguarda tan poderosa. Sin ella, te arriesgarías constantemente a dejar tus datos en un estado corrupto o incoherente, especialmente en sistemas en los que tienen que ocurrir varias cosas en secuencia.

Veamos algunos escenarios del mundo real en los que la atomicidad hace (o rompe) el sistema:

Ejemplo 1: Transferencia bancaria

Supongamos que transfieres 100 $ de tu cuenta corriente a tu cuenta de ahorro.

La transacción tiene dos partes:

1. Deducir 100 $ de la cuenta corriente
2. Añade 100 $ a los ahorros

Sin atomicidad, es posible que el paso uno se complete y el paso dos falle, tal vez debido a un fallo de la red o a una caída del servidor. Enhorabuena, tu dinero acaba de desvanecerse en el vacío. La atomicidad garantiza que, o bien ambos pasos tienen éxito, o bien ninguno. Si algo sale mal, los 100$ se quedan exactamente donde estaban al principio.

Ejemplo 2: Inventario y procesamiento de pedidos

Estás comprando en Internet el último disco de vinilo de edición limitada. El sistema necesita

1. Reduce el inventario en uno
2. Confirma tu pedido

Sin atomicidad, podría reducir el inventario, pero colapsar antes de que se confirme el pedido. Ahora la tienda cree que está agotado, pero nadie recibe el disco. 

La cantidad de veces que me pasa esto al comprar algo por Internet es asombrosa. Suelo cerrar la pestaña y desear buena suerte a sus ingenieros, pero lo más probable es que no intente comprar en ese sitio web en el futuro. ¿Quién sabe cómo tratarán mis datos personales si no pueden garantizar que su función principal de compra sea fiable?

Ejemplo 3: Sistema de reserva de vuelos

Reservar un vuelo suele ser algo más que seleccionar un asiento. El sistema necesita

1. Asigna el asiento
2. Actualizar disponibilidad de plazas
3. Carga tu tarjeta

Si el paso dos falla y el paso tres sigue adelante, habrás pagado por una plaza que no existe. No es lo ideal.

Ejemplo 4: Sincronización de la base de datos y el índice de búsqueda

Supongamos que tu aplicación actualiza la descripción de un producto en la base de datos principal. Al mismo tiempo, debe actualizar el índice de búsqueda para que los usuarios puedan encontrar el producto con la nueva descripción.

Si la actualización de la base de datos se realiza correctamente, pero la actualización del índice falla, los usuarios verán resultados obsoletos o no podrán encontrar el producto.

Por qué importa la atomicidad

Entonces, ¿por qué es tan importante la atomicidad? 

Hay muchas razones por las que una transacción puede interrumpirse. Podría producirse un corte de electricidad, una caída del servidor o una interrupción de la red a mitad de camino. Si no se aplica la atomicidad, esa transacción podría completarse sólo parcialmente. Ahora tu base de datos ha quedado en un estado incómodo: algunos cambios se han realizado, otros no, y no tienes forma fácil de deshacer el entuerto.

Aquí es donde los errores de datos se vuelven realmente furtivos. Los usuarios pueden no notar nada malo al principio, pero con el tiempo las cosas dejan de cuadrar. Tus analíticas tienen un aspecto extraño, los pedidos desaparecen, las cuentas no cuadran o los tickets de soporte se disparan porque la gente no puede encontrar lo que acaba de guardar.

La atomicidad evita todo eso garantizando que:

• Una transacción se realiza completamente o no se realiza en absoluto
• El sistema puede recuperarse limpiamente incluso si algo falla a mitad de camino
• Tus datos permanecen consistentes, incluso durante caídas del sistema o accesos concurrentes

También está estrechamente relacionado con las demás propiedades ACID. Sin atomicidad, la coherencia desaparece, porque no puedes aplicar reglas si faltan la mitad de los datos, y el aislamiento se rompe, ya que otros usuarios podrían ver datos parciales de una transacción incompleta.

Es especialmente importante si te enfrentas a:

• Transacciones de varios pasos, en las que una acción depende de otra.
• Actualizaciones de varias filas o tablas, en las que es necesario mantener sincronizados los datos relacionados.
• Sistemas distribuidos, donde partes de la transacción ocurren en diferentes máquinas o bases de datos.

Cómo funciona la atomicidad en la práctica

Detrás de la simplicidad del "todo o nada" se esconde un sistema sorprendentemente intrincado. Cuando una base de datos ejecuta una transacción, está siguiendo, preparando y protegiendo activamente cada paso.

He aquí una visión de alto nivel de lo que está ocurriendo:

El ciclo de vida de la transacción

1. Inicia la transacción: El sistema marca el inicio de una transacción, aislando los próximos cambios del resto de la base de datos.
2. Ejecuta la operación: Esto incluye todas tus inserciones, actualizaciones, eliminaciones o cualquier magia SQL que estés haciendo.
3. Confirmar o deshacer: Si cada operación tiene éxito, la transacción se confirma y los cambios se hacen permanentes. Si algo falla, se anula toda la transacción.

Registro y diario

Para garantizar la atomicidad, las bases de datos escriben registros de lo que va a ocurrir antes de que ocurra realmente. Estos registros se almacenan por separado y actúan como un plan de reserva.

Si el sistema se bloquea en mitad de una transacción, puede consultar el registro y deshacer los cambios incompletos, volver a aplicar los completados de forma segura y restaurar la base de datos a un estado limpio y coherente.

Este enfoque se denomina a veces registro de escritura en cabeza (WAL) o registro en diario, y es una pieza clave de la recuperación de fallos.

Retrocesos y recuperación

Cuando falla una transacción, la base de datos no se rinde sin más, sino que deshace cuidadosamente los cambios. Las filas modificadas se restauran a su estado original, se liberan los bloqueos que pudiera tener la transacción y se utilizan los registros para revertir las actualizaciones parciales.

Ahora, en caso de fallo, las rutinas de recuperación se activan en el momento del reinicio. Vuelven a reproducir los registros, resuelven las transacciones inacabadas y se aseguran de que la base de datos continúe justo donde lo dejó, sin extraños estados intermedios.

Rendimiento frente a atomicidad

Como es lógico, todo esto tiene un coste. Atomicidad presenta:

• Bloqueo: Para evitar que otros modifiquen los mismos datos a mitad de la transacción
• Sobrecarga: De los mecanismos de registro y reversión
• Bloqueos: Cuando varias transacciones esperan unas a otras para liberar recursos

Por eso tienes que diseñar cuidadosamente las transacciones grandes. Si haces demasiado de una sola vez, podrías ralentizar todo el sistema o tener problemas de concurrencia.

Atomicidad en sistemas de bases de datos populares

La atomicidad es un concepto básico en todas las bases de datos importantes, pero la forma en que se implementa puede variar ligeramente según el motor de almacenamiento subyacente y la filosofía de diseño. Veamos cómo PostgreSQL y MySQL (InnoDB) se aseguran de que las transacciones funcionan correctamente.

PostgreSQL

Antes de escribir cualquier dato de forma permanente, PostgreSQL crea un registro de escritura anticipada (WAL), el registro de cada cambio previsto del que hemos hablado antes. Este registro se almacena de forma segura y se utiliza como plan de recuperación en caso de que algo vaya mal durante la transacción.

Cuando se confirma una transacción, PostgreSQL comprueba la WAL, confirma que todos los cambios están completos y son válidos, y luego finaliza las actualizaciones. Si algo se bloquea a medio camino, la base de datos utiliza ese registro para deshacer el trabajo incompleto.

Lo mejor es que todo esto ocurre automáticamente entre bastidores. Desde el punto de vista de un desarrollador, es perfecto: escribes una transacción, y PostgreSQL garantiza la atomicidad sin que tengas que gestionar ninguna de las complejidades.

Los cambios no son visibles para los demás usuarios hasta que la transacción esté totalmente confirmada. Eso mantiene la coherencia y evita cualquier rareza "a medias" en entornos multiusuario.

PostgreSQL WAL. Fuente: AlgoMaster

Si quieres ponerte manos a la obra y crear tus propias bases de datos para probar transacciones, echa un vistazo a nuestro curso de PostgreSQL.

MySQL (InnoDB)

El motor de almacenamiento InnoDB de MySQL también admite transacciones atómicas, y su enfoque está pensado tanto para la fiabilidad como para el rendimiento.

Al igual que PostgreSQL, InnoDB utiliza un registro de transacciones para realizar un seguimiento de los cambios antes de consignarlos. Si algo falla, el registro se utiliza para volver todo al estado anterior a la transacción. Esto garantiza que no se cuelen actualizaciones parciales.

Algo que InnoDB hace especialmente bien es agrupar las escrituras. Esto ayuda a reducir la E/S de disco y mejora el rendimiento, sin dejar de proteger la atomicidad. También utiliza registros de deshacer para revertir los cambios durante una reversión y registros de rehacer para la recuperación tras un fallo.

Al igual que en PostgreSQL, puedes confiar en que la base de datos gestione estos mecanismos por ti. No tienes que escribir ningún código de retroceso personalizado.

Puntos clave para ingenieros y arquitectos de datos

Hay algunas cosas que debes tener en cuenta cuando trabajes con transacciones atómicas en tus propios proyectos. La idea general es tratar la atomicidad como un valor por defecto, no como un lujo. Si estás construyendo sistemas que modifican datos en más de un lugar a la vez (que son básicamente todos), diseñar teniendo en cuenta la atomicidad te ahorrará tiempo, cordura y, potencialmente, una notificación de incidente a las 3 de la madrugada. 

Elige la base de datos adecuada para el trabajo

No todas las bases de datos gestionan la atomicidad de la misma manera, y no todos los motores de almacenamiento son iguales. Si la atomicidad es crítica para tu caso de uso (por ejemplo, finanzas, logística, gestión del estado del usuario), asegúrate de que tu base de datos admite transacciones ACID completas. Esto es especialmente relevante si utilizas MySQL, donde la elección del motor de almacenamiento importa.

Diseño para el fracaso

Asume que las cosas irán mal, porque irán mal. Envuelve las operaciones de varios pasos en transacciones y gestiona los errores adecuadamente. Sé explícito con tus declaraciones BEGIN,COMMIT, y ROLLBACK, o utiliza frameworks que las manejen con seguridad bajo el capó.

La mayoría de los ORM y capas de acceso a datos modernos ofrecen soporte incorporado para transacciones. Por ejemplo:

• En Node.js, librerías como Prisma y TypeORM te permiten envolver la lógica en una transaction() que gestiona la confirmación/retroceso entre bastidores.

• En Python, SQLAlchemy ofrece gestores de contexto (con session.begin():) que garantizan confirmaciones y reversiones seguras.

• En Java, los marcos de trabajo como Spring te permiten anotar métodos con @Transactionalpara que la base de datos lo gestione todo atómicamente, incluso a través de múltiples llamadas a funciones.

Estas herramientas facilitan mucho la construcción segura por defecto. Reducen el riesgo de olvidar un rollback o de gestionar mal la lógica de commit, especialmente cuando tu aplicación se vuelve más compleja.

Equilibra el rendimiento con la fiabilidad

La atomicidad conlleva cierta sobrecarga, especialmente en las transacciones grandes. Divide las operaciones masivas siempre que sea posible, evita bloquear tablas enteras y mantén las transacciones cortas y centradas. Las transacciones de larga duración aumentan el riesgo de contención, bloqueos y usuarios insatisfechos.

Comprender las dependencias y el aislamiento

Como hemos visto antes, la atomicidad no existe en el vacío, sino junto con la coherencia y el aislamiento. Asegúrate de que los cambios relacionados se producen juntos, y considera cómo podrían interactuar las transacciones concurrentes. Utiliza niveles de aislamiento que se adapten a tu carga de trabajo sin complicar demasiado las cosas.

Propiedades ACID en SGBD. Fuente: Datacamp

Prueba con escenarios de fallo realistas

No te limites a probar tus caminos felices. Simula lo que ocurre cuando tu aplicación se bloquea en mitad de una transacción, o cuando se agota el tiempo de una consulta. Puedes utilizar puntos de fallo o fallos simulados de la BD para ver cómo se comporta tu sistema bajo presión.

Conclusión

Si construyes sistemas en los que tienen que ocurrir varias cosas a la vez, la atomicidad no es opcional, es esencial. Tanto si estás moviendo dinero entre cuentas, actualizando el inventario o sincronizando sistemas, la atomicidad garantiza que tus datos no acaben en un estado roto o a medias.

Si quieres profundizar más, ¿por qué no sigues nuestro curso de Diseño de Bases de Datos? Aprenderás a diseñar bases de datos en SQL para procesar, almacenar y organizar datos de forma más eficiente.

Y si te interesan más artículos y tutoriales prácticos sobre diseño de bases de datos, echa un vistazo a nuestra serie sobre normalización de bases de datos:

• Normalización en SQL (1NF - 5NF): Guía para principiantes tutorial
• ¿Qué es la Primera Forma Normal (1NF)? tutorial
• ¿Qué es la Segunda Forma Normal (2NF)? tutorial
• ¿Qué es la Tercera Forma Normal (3NF)? Tutorial
• ¿Qué es la dependencia transitiva? Tutorial