--- title: 'Bases de datos y transacciones distribuidas: aislamiento, bloqueos y patrones de consenso' description: 'Una guía completa sobre transacciones en bases de datos, condiciones de carrera, bloqueo optimista frente a pesimista, bloqueos distribuidos basados en Redis, 2PC, orquestación/coreografía de Sagas y el patrón Transactional Outbox con intermediarios de mensajes.' faq: - { question: '¿Cuál es la diferencia entre el bloqueo optimista y el pesimista?', answer: 'El bloqueo pesimista evita problemas de concurrencia bloqueando las filas de la base de datos (mediante SELECT FOR UPDATE), impidiendo que otras transacciones accedan a ellas hasta que se libere el bloqueo. El bloqueo optimista asume que los conflictos son raros; permite operaciones concurrentes pero verifica una columna de versión o marca de tiempo durante las actualizaciones. Si otra transacción modificó la fila en el ínterin, la actualización falla y la aplicación debe reintentarlo.' } - { question: '¿Por qué el compromiso de dos fases (2PC) se utiliza poco en microservicios modernos?', answer: 'El compromiso de dos fases es un protocolo síncrono y bloqueante. Requiere que todos los servicios participantes bloqueen recursos durante ambas fases. Si un servicio se ralentiza o se desconecta, todos los demás permanecen bloqueados, creando un único punto de fallo y limitando severamente la escalabilidad y disponibilidad del sistema.' } - { question: "¿Cómo garantiza el patrón Transactional Outbox la entrega 'al menos una vez' (at-least-once)?", answer: "En lugar de publicar un mensaje directamente en un intermediario de mensajes (broker) durante una transacción de base de datos (lo que podría fallar si el broker está fuera de línea), el servicio escribe tanto los datos de negocio como el cuerpo del mensaje en una tabla 'outbox' dentro de la misma transacción local. Un proceso en segundo plano independiente consulta esta tabla de forma asíncrona, envía los mensajes al broker y los marca como procesados, garantizando que no se pierda ningún mensaje." } published: '2026-06-14' --- # Bases de datos y transacciones distribuidas: aislamiento, bloqueos y patrones de consenso Imagine a un usuario que intenta reservar el último asiento disponible en un vuelo. Dos solicitudes llegan a los servidores de aplicaciones exactamente en el mismo milisegundo. Si el sistema no está diseñado para manejar la concurrencia, ambas solicitudes leerán el estado del asiento como \"disponible\", descontarán el pago y emitirán dos billetes para el mismo asiento. Este clásico problema de doble reserva es una pesadilla tanto para desarrolladores como para empresas. En un sistema monolítico con una sola base de datos, las transacciones SQL pueden evitar esto fácilmente. Pero en un sistema distribuido, donde el servicio de reserva de asientos, la pasarela de pago y el sistema de notificaciones son microservicios aislados, una transacción simple de base de datos ya no es suficiente. El diseño de sistemas transaccionales robustos requiere adaptar la granularidad del bloqueo a la escala arquitectónica, pasando de simples bloqueos SQL para el estado local a patrones de consenso distribuidos para la consistencia entre servicios. ## Tabla de contenidos * [Transacciones locales: ACID y niveles de aislamiento](#acid-isolation) * [Condiciones de carrera: bloqueo pesimista frente a optimista](#locking-strategies) * [Bloqueos distribuidos a escala: soluciones basadas en Redis](#redis-locks) * [Transacciones distribuidas: la caída del compromiso de dos fases (2PC)](#distributed-2pc) * [Consistencia eventual: Saga y Transactional Outbox](#saga-outbox) * [Demostración práctica de código en PHP y Laravel](#code-demo) * [Limitaciones y compromisos](#limitations) * [Conclusiones prácticas](#takeaways) --- ## Transacciones locales: ACID y niveles de aislamiento En el núcleo de la integridad de los datos se encuentra el modelo ACID: atomicidad (Atomicity), consistencia (Consistency), aislamiento (Isolation) y durabilidad (Durability). Mientras que la atomicidad (\"todo o nada\") y la durabilidad (almacenamiento permanente) son sencillas, el aislamiento es donde el rendimiento y la corrección entran en conflicto. Las bases de datos ofrecen cuatro niveles de aislamiento estándar para gestionar el acceso concurrente, cada uno de los cuales evita diferentes anomalías: 1. **Read Uncommitted (Lectura no comprometida)**: El nivel más bajo. Una transacción puede leer cambios no confirmados de otra transacción (Dirty Reads o lecturas sucias). 2. **Read Committed (Lectura comprometida)**: Evita lecturas sucias. Una consulta solo lee datos confirmados antes de que comenzara la consulta. Sin embargo, si vuelve a ejecutar la consulta, podría ver cambios confirmados por otras transacciones mientras tanto (Non-repeatable Reads o lecturas no repetibles). 3. **Repeatable Read (Lectura repetible)**: Evita lecturas no repetibles. Los datos leídos durante la transacción son consistentes. En algunas bases de datos, esto no evita que otras transacciones inserten nuevas filas (Phantom Reads o lecturas fantasma). 4. **Serializable (Serializable)**: El nivel más alto. Las transacciones se ejecutan de manera que producen el mismo resultado que si se ejecutaran secuencialmente, eliminando todas las anomalías de concurrencia a costa de graves límites de rendimiento. La mayoría de las bases de datos relacionales (como PostgreSQL y MySQL) utilizan por defecto **Read Committed** o **Repeatable Read**. Para lograr una seguridad total sin sacrificar el rendimiento, los desarrolladores deben controlar explícitamente los bloqueos en lugar de confiar únicamente en el nivel de aislamiento global de la base de datos. --- ## Condiciones de carrera: bloqueo pesimista frente a optimista Cuando varios clientes intentan modificar la misma fila de la base de datos simultáneamente, debemos elegir una estrategia de bloqueo. ### Bloqueo pesimista (Pessimistic Locking) * **Punto**: Asume que los conflictos son muy probables y bloquea el acceso de forma proactiva. * **Por qué es importante**: Evita condiciones de carrera directamente en la base de datos utilizando sus mecanismos internos de bloqueo. * **Ejemplo**: Ejecutar `SELECT ... FOR UPDATE` bloquea las filas seleccionadas. Cualquier otra transacción que intente leer esas filas con `FOR UPDATE` o modificarlas se bloqueará hasta que la primera transacción se confirme o se revierta. * **Consecuencia**: Alta seguridad pero baja concurrencia. Si las transacciones tardan mucho tiempo (por ejemplo, esperando respuestas de red externas), otros hilos de la base de datos agotan rápidamente el pool de conexiones, lo que provoca la caída de la aplicación. ### Bloqueo optimista (Optimistic Locking) * **Punto**: Asume que los conflictos son raros, permitiendo lecturas concurrentes pero validando durante las escrituras. * **Por qué es importante**: Evita por completo los bloqueos en la base de datos, maximizando el rendimiento de lectura y la escalabilidad. * **Ejemplo**: Cada fila tiene una columna de `version` (entero) o `updated_at` (marca de tiempo). Al actualizar, la sentencia SQL se estructura como: ```sql UPDATE inventory SET quantity = quantity - 1, version = version + 1 WHERE id = 1 AND version = 3; ``` * **Consecuencia**: Si otra transacción actualizó la fila primero, la versión sería 4, y esta consulta actualizaría 0 filas. La aplicación detecta esto y decide si reintentar o fallar. Sin embargo, bajo una alta contención de escritura, los reintentos frecuentes pueden degradar el rendimiento. --- ## Bloqueos distribuidos a escala: soluciones basadas en Redis En aplicaciones de alta concurrencia, el bloqueo en la base de datos puede sobrecargar su CPU. Además, si necesita bloquear un proceso de negocio que no está mapeado a una fila específica, o bloquear operaciones entre diferentes sistemas, los bloqueos de base de datos son insuficientes. * **Punto**: Utilizar un almacenamiento en memoria rápido como Redis para gestionar bloqueos fuera de la base de datos relacional. * **Por qué es importante**: Las operaciones de Redis son de un solo hilo y se ejecutan de forma atómica, lo que las hace extremadamente rápidas (sub-milisegundo) y libera conexiones de base de datos. * **Ejemplo**: Un proceso adquiere un bloqueo utilizando el comando atómico `SET lock_key unique_token NX PX 5000` (establecer si no existe, expira después de 5000 ms). Al liberarlo, un script de Lua verifica que el proceso actual posea el token único antes de eliminar la clave. * **Consecuencia**: Altamente escalable. Sin embargo, si Redis se cae, o en un entorno de clúster donde un maestro falla antes de replicar el bloqueo a una réplica (split-brain), se podrían emitir bloqueos duplicados. El algoritmo Redlock resuelve esto adquiriendo bloqueos en múltiples nodos de Redis independientes. --- ## Transacciones distribuidas: la caída del compromiso de dos fases Al pasar a una arquitectura de microservicios, los datos se dividen entre los límites de los servicios. Una transacción de negocio puede abarcar un Servicio de Clientes, un Servicio de Inventario y un Servicio de Pagos. Históricamente, la solución estándar para transacciones distribuidas era el **Compromiso de dos fases (2PC)**: 1. **Fase de preparación (Prepare)**: Un coordinador pregunta a todos los servicios participantes si están listos para confirmar. Los servicios bloquean sus recursos locales y responden \"sí\". 2. **Fase de compromiso (Commit)**: Si todos los servicios respondieron \"sí\", el coordinador les ordena confirmar. Si alguno respondió \"no\", les ordena revertir (rollback). Aunque conceptualmente es simple, 2PC es un **protocolo síncrono y bloqueante**. Si la red falla o un servicio se desconecta durante la fase de compromiso, los recursos permanecen bloqueados indefinidamente. Esto reduce drásticamente el rendimiento y viola el principio de disponibilidad del teorema CAP. Los sistemas distribuidos modernos intercambian consistencia atómica por consistencia eventual. --- ## Consistencia eventual: Saga y Transactional Outbox Para lograr confiabilidad entre múltiples microservicios sin bloquear recursos, utilizamos patrones de diseño asíncronos. ### Patrón Saga Una Saga es una secuencia de transacciones locales. Cada servicio actualiza su base de datos en una transacción local y publica un evento. Otros servicios escuchan este evento y ejecutan sus transacciones locales. Si una transacción falla, la Saga ejecuta **transacciones compensatorias** en orden inverso para deshacer los cambios. * **Coreografía**: Los servicios publican y se suscriben a eventos sin un coordinador central. Rápido y desacoplado, pero difícil de rastrear en flujos complejos. * **Orquestación**: Un servicio central orquesta el flujo, llamando a los servicios y gestionando la lógica de compensación. Más fácil de modelar, pero introduce un único punto de orquestación. ### Patrón Transactional Outbox Un antipatrón común es publicar un evento en un intermediario de mensajes (como RabbitMQ) directamente dentro de una transacción de base de datos. Si el broker está fuera de línea, la transacción se revierte. Si el broker tiene éxito pero la base de datos falla al confirmar, se generan eventos fantasma. El patrón **Transactional Outbox** resuelve esto: 1. Escriba tanto los cambios del modelo de dominio como los datos del evento (en una tabla `outbox`) dentro de la misma transacción de base de datos. 2. Un proceso independiente en segundo plano (Message Relay) consulta la tabla `outbox`, publica los mensajes en el broker y los marca como enviados. 3. Esto garantiza la **entrega al menos una vez**. El receptor debe implementar **idempotencia** (procesar el mismo mensaje dos veces produce el mismo resultado) para manejar duplicados de forma segura. --- ## Demostración práctica de código en PHP y Laravel Aquí se muestra cómo puede implementar estos patrones en una aplicación Laravel. ### 1. Transacción de base de datos con bloqueo pesimista ```php // app/Services/BookingService.php namespace App\Services; use Illuminate\Support\Facades\DB; use App\Models\FlightSeat; class BookingService { public function bookSeat(int $seatId, int $userId): bool { return DB::transaction(function () use ($seatId, $userId) { // Bloquea la fila para la actualización. Otros hilos se bloquean aquí. $seat = FlightSeat::where('id', $seatId) ->lockForUpdate() ->first(); if (!$seat || $seat->is_booked) { return false; } $seat->update([ 'is_booked' => true, 'user_id' => $userId, ]); return true; }); } } ``` ### 2. Bloqueo distribuido con Redis ```php // app/Services/InventoryService.php namespace App\Services; use Illuminate\Support\Facades\Cache; class InventoryService { public function decreaseStock(int $productId, int $quantity): bool { $lockKey = "lock:product:{$productId}"; // Intenta adquirir el bloqueo por 10 segundos, espera hasta 3 segundos. $lock = Cache::lock($lockKey, 10); if ($lock->get()) { try { // Actualización rápida y no bloqueante // ... lógica de actualización de stock return true; } finally { $lock->release(); } } return false; } } ``` ### 3. Inserción en Transactional Outbox ```php // app/Services/OrderService.php namespace App\Services; use Illuminate\Support\Facades\DB; use App\Models\Order; use App\Models\OutboxMessage; class OrderService { public function createOrder(array $data): Order { return DB::transaction(function () use ($data) { $order = Order::create($data); // Registra el evento dentro de la misma transacción OutboxMessage::create([ 'event_type' => 'order.created', 'payload' => json_encode([ 'order_id' => $order->id, 'user_id' => $order->user_id, 'total' => $order->total_amount, ]), 'processed' => false, ]); return $order; }); } } ``` --- ## Limitaciones y compromisos * **Bloqueo optimista**: Bajo cargas de escritura concurrentes extremadamente altas, las actualizaciones optimistas fallarán con frecuencia, lo que provocará errores en las solicitudes de los clientes o un alto uso de CPU durante los reintentos. * **Bloqueos de Redis**: Un bloqueo es tan seguro como su tiempo de expiración (TTL). Si un proceso tarda más de la duración del bloqueo (por ejemplo, debido a una pausa por recolección de basura), el bloqueo expira, otro proceso lo adquiere y se pierde la exclusión mutua. * **Sagas**: Las transacciones compensatorias no pueden deshacer físicamente los efectos secundarios externos (como enviar un correo electrónico o realizar un cargo bancario). Por lo tanto, el flujo de negocio debe diseñarse con estados intermedios (como retención de fondos o borradores de correos). --- ## Conclusiones prácticas 1. Utilice **bloqueo optimista** para operaciones con un alto volumen de lectura y conflictos poco frecuentes (por ejemplo, edición de contenido o actualizaciones de perfiles). 2. Utilice **bloqueo pesimista** (`SELECT ... FOR UPDATE`) para transacciones financieras críticas con concurrencia moderada, donde los conflictos deben resolverse dentro de la base de datos. 3. Utilice **bloqueos de Redis** para proteger flujos de trabajo en el servidor y evitar que varios workers ejecuten tareas idénticas simultáneamente. 4. Para microservicios, evite transacciones distribuidas síncronas (como 2PC). Implemente el **patrón Saga** para la orquestación y el **patrón Transactional Outbox** para garantizar una entrega asíncrona y confiable de eventos.