Manejo de transacciones distribuidas con Sagas en microservicios: ¿cómo evitar deadlocks?

DigitalArt

Estoy implementando un flujo de pedidos con microservicios (inventario, pagos, envíos) usando el patrón Saga coreografiado. Todo funciona bien en entornos controlados, pero en producción con alta concurrencia empiezo a ver deadlocks en los servicios que usan PostgreSQL (aislamiento READ COMMITTED). Por ejemplo, el servicio de inventario bloquea filas para reservar stock, y otro saga request queda esperando indefinidamente. He probado con timeout y retry, pero a veces los deadlocks persisten. ¿Alguien ha solucionado esto sin migrar a un modelo de eventos completamente asíncrono? Estoy usando Spring Boot y Kafka para los mensajes del saga.

Polyglot

Usuario1:

Hemos tenido el mismo problema. La clave está en la estrategia de bloqueo. En lugar de usar bloqueos pesimistas (SELECT ... FOR UPDATE), intenta usar bloqueos optimistas con versionado de filas (columna version). Si el conflicto es frecuente, un enfoque es rediseñar la saga para que el paso de reserva sea compensable con un timeout forzado (ej: TTL en Redis). Otra opción es usar un orden fijo de adquisición de bloqueos entre servicios para evitar deadlocks.

Crochet

Usuario2:

Coincido con Usuario1, pero añadiría que el problema no es solo el bloqueo, sino la semántica de la saga. Si usas coreografía, cada servicio maneja su propio estado, y los deadlocks pueden ocurrir cuando dos sagas intentan modificar el mismo recurso en orden inverso. Una solución práctica es implementar un lock manager distribuido (ej: con Redisson) para cada recurso crítico, con un tiempo de lease corto. Eso evita deadlocks aunque sea más overhead.

Meditation

Usuario3:

No estoy seguro de que los bloqueos distribuidos sean la solución. Añaden latencia y un punto único de fallo. Nosotros optamos por cambiar a un modelo de orquestación con un solo coordinador que maneja el orden de las transacciones. Así controlamos el acceso secuencial a los recursos compartidos. También usamos SKIP LOCKED en las consultas de inventario para evitar esperar filas bloqueadas.

Quilting

Usuario4:

Prueba a reducir el tiempo de las transacciones de base de datos. En nuestro caso, los deadlocks desaparecieron al mover la lógica de reserva a una tabla separada con índices adecuados y usando FOR UPDATE NOWAIT con captura de excepción. Si falla, la saga lanza un evento de fallo inmediato y reintenta después. También es recomendable usar un isolation level SERIALIZABLE si el volumen lo permite, pero cuidado con la performance.

DigitalArt

Gracias a todos por las sugerencias. Me llama la atención lo de SKIP LOCKED y NOWAIT. Voy a probar combinando eso con un orden estricto de acceso a las tablas (siempre inventario antes que pagos). También consideraré el lock manager distribuido como plan B. ¿Alguien ha tenido problemas con la consistencia eventual al usar SKIP LOCKED? En teoría, si saltas una fila, podrías perder una reserva válida si no hay reintento.

Hiking

Usuario5:

Exacto, con SKIP LOCKED necesitas un mecanismo de reintento con backoff exponencial para no perder reservas. Asegúrate de que la lógica de compensación (rollback) también sea idempotente. Nosotros lo resolvimos combinando SKIP LOCKED con una cola de reintentos en Kafka. Si una reserva falla, se publica un evento de reintento con un retardo. Funciona bien con cargas altas.

Chess

Usuario6:

Otra alternativa: usar un enfoque de outbox pattern para las reservas. En lugar de bloquear en la base de datos, encolas un mensaje y luego un consumidor procesa la reserva de forma asíncrona con bloqueo optimista. Así reduces la contención. La compensación se maneja con un proceso de reconciliación periódico. Es más complejo, pero escala mejor.

Knitting

El outbox pattern escala mejor, pero introduce latencia y complejidad en la compensación. Si optas por SKIP LOCKED + reintentos, asegúrate de que el backoff sea exponencial con jitter para evitar tormentas de reintentos. En mi experiencia, combinar SKIP LOCKED con un orden estricto de recursos y timeouts cortos (< 1s) reduce deadlocks drásticamente. ¿Alguien ha probado el patrón de 'blocking queue' con PostgreSQL? SELECT ... FOR UPDATE SKIP LOCKED en un bucle con pg_sleep escalonado puede ser más simple que Kafka para casos de baja latencia.