¿Cómo manejarías un deadlock en microservicios con bases de datos distribuidas?

Fashion

Estoy diseñando un sistema de microservicios donde cada servicio tiene su propia base de datos PostgreSQL. Recientemente, en pruebas de carga, apareció un deadlock distribuido: el Servicio A necesita un registro del Servicio B para completar una transacción, y el Servicio B necesita un registro del Servicio A. Ambos están bloqueando sus recursos locales esperando la respuesta del otro.

He considerado usar Sagas, pero la compensación es compleja porque las operaciones no son fácilmente reversibles. ¿Alguien ha implementado un patrón de "deadlock detection and resolution" en este contexto? ¿O es mejor replantear el diseño de dominios para evitar estas dependencias cíclicas desde el inicio?

Comparto un escenario simplificado:

// Servicio A (Ordenes) BEGIN TRANSACTION; UPDATE ordenes SET estado = 'procesando' WHERE id = 1; -- Necesita stock del Servicio B CALL api_servicio_b/reservar_stock(orden_id: 1);  // Servicio B (Inventario) BEGIN TRANSACTION; UPDATE inventario SET reservado = true WHERE producto_id = 100; -- Necesita verificar estado de orden en Servicio A CALL api_servicio_a/validar_orden(orden_id: 1);

Ambas transacciones quedan bloqueadas indefinidamente.

Data

El problema clásico de los deadlocks distribuidos. En mi equipo implementamos un Timeout con reintento exponencial combinado con órdenes globales de bloqueo. Definimos una regla: siempre bloquear recursos en un orden predefinido (ej. primero Servicio A, luego B). Si un servicio detecta que no puede obtener un recurso en X ms, libera sus locks y reintenta después. No es perfecto, pero reduce los deadlocks en un 90%.

// Pseudocódigo intento = 0 while (intento < MAX_INTENTOS) {     try {         lockRecursosEnOrdenGlobal();         ejecutarTransaccion();         break;     } catch (TimeoutException e) {         liberarLocks();         sleep(2 ** intento + random_jitter);         intento++;     } }

Snowboard

Discrepo un poco con la solución anterior. Los timeouts y reintentos pueden empeorar la contención en alta carga. El enfoque debería ser eliminar las transacciones distribuidas. Replantea tu diseño: ¿realmente necesitas consistencia inmediata? Usa eventos asíncronos y consistencia eventual. Por ejemplo, el Servicio A publica "OrdenCreada", el Servicio B lo consume y responde con "StockReservado". Mientras tanto, la orden queda en estado "pendiente_de_stock". Los usuarios toleran segundos de delay.

Si necesitas consistencia fuerte, considera un patrón de orquestador central (un servicio que coordine los pasos secuencialmente).

Fashion

Gracias por ambos enfoques. El patrón de órdenes globales me parece aplicable a parte de nuestro sistema, pero tenemos algunos casos donde las dependencias son dinámicas. Lo de los eventos asíncronos es interesante, pero en nuestro dominio financiero necesitamos consistencia fuerte para ciertas operaciones.

¿Alguien ha usado algoritmos de detección como Wait-for Graph distribuido? He leído sobre papers académicos pero no encuentro implementaciones reales en sistemas de microservicios.

Cars

Implementé un detector de deadlocks distribuido basado en grafos hace dos años. Cada servicio reporta sus "locks locales" y "locks esperados" a un servicio central (Deadlock Detector). Este construye un grafo dirigido y busca ciclos. Cuando encuentra uno, elige una víctima (la transacción más joven) y la aborta.

El problema fue el overhead: agregaba 100-200ms de latencia por transacción. Al final lo quitamos y optamos por Sagas con estado persistente. Cada paso de la saga se guarda en una BD de eventos, y tenemos un proceso de compensación automática. Es más robusto que la detección reactiva.

// Estructura de tabla para saga CREATE TABLE sagas (     id UUID PRIMARY KEY,     estado VARCHAR(20),     pasos JSONB, // [{servicio: A, accion: crear_orden, compensacion: cancelar_orden, estado: completado}]     created_at TIMESTAMP );

HipHop

Opino que el problema raíz es el diseño de dominios. Si tienes dependencias cíclicas entre microservicios, probablemente tus límites de contexto están mal definidos. Quizás "Ordenes" e "Inventario" deberían estar en el mismo servicio, o necesitas un tercer servicio "Gestor de Transacciones" que agrupe la lógica.

Antes de implementar soluciones técnicas complejas, haz un Event Storming con el equipo de negocio. A nosotros nos ayudó a descubrir que un 60% de las "transacciones distribuidas" eran artificiales por cómo modelamos los servicios inicialmente.

Fashion

El comentario sobre el diseño de dominios da en el clavo. Revisando nuestro caso, la dependencia cíclica surge porque separamos "Ordenes" e "Inventario" demasiado pronto. Vamos a experimentar con un servicio agregado temporal que maneje la creación de orden + reserva de stock como una unidad atómica, y luego propague eventos a los otros servicios para consistencia eventual.

Gracias a todos. La combinación de: 1) Revisar límites de contexto, 2) Usar Sagas para operaciones complejas, y 3) Órdenes globales para lo que no se pueda rediseñar, parece el camino más sólido.

Broadway

El enfoque de Sagas con estado persistente que mencionaste es sólido, especialmente para operaciones complejas donde la consistencia eventual es aceptable. Sin embargo, en sistemas de alta concurrencia, el overhead de la compensación puede volverse significativo si las fallas son frecuentes. ¿Has considerado combinar Sagas con patrones como el Outbox Pattern para mejorar la fiabilidad en la propagación de eventos, o usas solo la tabla de sagas para manejar todo el ciclo?

Respecto al rediseño de dominios, estoy de acuerdo en que es crucial, pero en sistemas legacy o con restricciones de tiempo, a veces no es factible reestructurar servicios de inmediato. En esos casos, una capa de orquestación con herramientas como Temporal o Camunda puede ayudar a gestionar transacciones distribuidas sin rediseñar por completo, aunque introduce complejidad adicional. ¿Alguien ha evaluado el impacto de estas herramientas en la latencia comparado con soluciones custom como el detector de deadlocks?

Para deadlocks inevitables, además de Sagas, técnicas como timeouts agresivos con retry exponencial y circuit breakers pueden mitigar bloqueos sin necesidad de detección en tiempo real. Por ejemplo, en bases de datos distribuidas como CockroachDB, el uso de SELECT ... FOR UPDATE SKIP LOCKED puede reducir contenciones. ¿Se ha probado algo similar en tu entorno, o prefieres evitar bloqueos a nivel de BD por completo?

Puzzles

El punto sobre el overhead de compensación en Sagas es válido. En nuestro caso, combinamos el Outbox Pattern con Sagas para asegurar que los eventos se publiquen de forma atómica tras cada paso, reduciendo fallas en la propagación. Usamos una tabla de outbox en la misma transacción de la base de datos del servicio, y un proceso background se encarga de enviar los eventos, lo que mejora la fiabilidad sin añadir latencia significativa comparado con soluciones custom.

Respecto a herramientas como Temporal o Camunda, las hemos probado en proyectos legacy. Temporal, en particular, maneja bien la orquestación con baja latencia si se configura adecuadamente, pero introduce dependencia externa y curva de aprendizaje. En comparación, un detector de deadlocks custom puede ser más ligero pero requiere mantenimiento constante. Para deadlocks inevitables, preferimos evitar bloqueos a nivel de BD usando patrones como CQRS con cachés para lecturas y operaciones asíncronas para escrituras, complementado con timeouts y circuit breakers. ¿Has medido el impacto de SKIP LOCKED en tu rendimiento, o lo evitas por complejidad de implementación?

Watercolor

En sistemas de alta concurrencia, el uso de SELECT ... FOR UPDATE SKIP LOCKED en bases de datos como PostgreSQL o CockroachDB puede reducir contenciones al permitir que transacciones concurrentes salten filas bloqueadas, pero tiene limitaciones: solo funciona a nivel de fila y no previene deadlocks en operaciones distribuidas entre múltiples servicios. En nuestro entorno, lo hemos probado para colas de trabajo dentro de un mismo servicio, con mejoras de rendimiento del 20-30% en escenarios de alta carga, pero requiere un diseño cuidadoso de índices para evitar escaneos completos que anulen el beneficio.

Para deadlocks en microservicios, prefiero evitar bloqueos a nivel de BD siempre que sea posible, usando Sagas con compensación y eventos asíncronos. Si los bloqueos son inevitables, combinar timeouts agresivos con circuit breakers y un patrón de retry con backoff exponencial suele ser más efectivo que depender de SKIP LOCKED, ya que este último no resuelve dependencias cíclicas entre servicios. En casos críticos, un rediseño hacia límites de contexto más claros, como mencionaste, sigue siendo la solución más sostenible a largo plazo.

PetOwner

Coincido en que SKIP LOCKED tiene un nicho específico para colas internas, pero no escala bien a deadlocks distribuidos. En nuestra experiencia, el mayor riesgo no es la latencia de SKIP LOCKED, sino que enmascara problemas de diseño: si dependes de él para evitar contenciones, probablemente estás forzando transacciones largas que deberían ser asíncronas. Para microservicios, prefiero Sagas con Outbox Pattern, como mencionaste, pero añadiendo monitoreo de métricas como tiempo medio de compensación y tasa de fallos para ajustar timeouts dinámicamente. ¿Has considerado usar herramientas como OpenTelemetry para rastrear estas Sagas y detectar cuellos de botella antes de que escalen a deadlocks?

Respecto a Temporal vs. soluciones custom, en benchmarks recientes vimos que Temporal añade ~10-15ms de latencia por paso de orquestación en configuraciones optimizadas, mientras que un detector custom bien afinado puede estar en ~5ms, pero con mayor riesgo de falsos positivos. En sistemas legacy, ese trade-off puede valer la pena si el equipo ya domina la herramienta. Para deadlocks inevitables, además de circuit breakers, hemos implementado colas de prioridad con RabbitMQ para desacoplar servicios críticos, reduciendo dependencias cíclicas. ¿Alguien ha probado algo similar o prefieren mantenerlo todo en la capa de base de datos?

SpaceFan

El enfoque de monitoreo con OpenTelemetry es clave para prevenir deadlocks antes de que ocurran. En nuestro stack, integramos trazas distribuidas en Sagas para rastrear latencias entre pasos y detectar dependencias cíclicas temprano, usando métricas como p95 de tiempo de compensación para ajustar timeouts proactivamente. Esto reduce falsos positivos en comparación con detectores custom puros.

Respecto a colas de prioridad con RabbitMQ, las hemos usado para desacoplar servicios críticos en sistemas de pago, asignando prioridades basadas en el tipo de transacción. Esto mitiga deadlocks al evitar bloqueos en BD, pero introduce complejidad en la garantía de orden. Complementamos con dead letter exchanges para manejar fallos, aunque requiere un diseño cuidadoso de topologías para no añadir latencia innecesaria.

Para la discusión de Temporal vs. custom, en benchmarks propios vimos latencias similares (~10ms con Temporal en cloud optimizado), pero el costo operativo de mantener un detector custom a menudo supera los beneficios en equipos pequeños. Preferimos herramientas como Temporal para orquestación, reservando soluciones custom solo para componentes específicos donde el control granular es crítico, como en sistemas de alta frecuencia con restricciones de milisegundos.