¿Cómo previenes deadlocks con miles de transacciones concurrentes?

Question

IT Interview Practice · Accepted Answer

**Adquiere los locks en un orden global consistente, mantén las transacciones cortas, baja el nivel de isolation donde sea seguro, y reintenta al perdedor cuando aún así ocurra un deadlock.** Un deadlock es un ciclo: la transacción A mantiene la fila 1 y espera la fila 2, mientras B mantiene la fila 2 y espera la fila 1 — ninguna puede avanzar, así que la DB mata a una.

## El ciclo que debes romper

```text
   Tx A                              Tx B
   holds row 1  ──── waits ────▶ row 2 (held by B)
        ▲                              │
        │ waits                        │ holds
        └────────── row 1 ◀────────────┘
                (cycle = deadlock; DB aborts one victim)
```

## Estrategias

- **Orden de locks consistente.** Si cada transacción siempre bloquea las filas en el mismo orden (p. ej. primary key ascendente), un ciclo es imposible — A y B ambas toman la fila 1 primero, así que una simplemente espera. Esta es la palanca individual más grande. Un bug clásico: una transferencia de dinero que bloquea las cuentas en orden `(from, to)` hace deadlock con la transferencia inversa; bloquea siempre por `min(id), max(id)`.
- **Transacciones cortas.** Mantén los locks el menor tiempo posible — haz la validación, las llamadas de red y las lecturas **antes** de `BEGIN`, luego bloquea, escribe y `COMMIT` rápido. Las transacciones largas ensanchan la ventana para ciclos y esperas de locks.
- **Baja el isolation donde sea seguro.** `SERIALIZABLE` toma más locks/range locks y hace más deadlocks; `READ COMMITTED` (default de Postgres) bloquea menos. Usa el isolation más débil que aún cumpla la correctitud.
- **Reintenta ante deadlock.** Los deadlocks son transitorios. Captura el error de deadlock (Postgres `40P01`, MySQL `1213`) y reintenta toda la transacción con un pequeño backoff. Algo de contención es inevitable a escala, así que el reintento es una red de seguridad, no un sustituto del ordenamiento.

## Perspectiva de la entrevista

El entrevistador comprueba si sabes que los deadlocks se **previenen por diseño, no solo se capturan**. Nombrar solo "reintento" es una respuesta débil — la respuesta excelente lidera con **orden de locks consistente** y **transacciones cortas**, luego añade reintento para el residual. Una trampa común: asumir que la app debe detectar los deadlocks; en la práctica la **DB detecta el ciclo y aborta una víctima** por ti — tu trabajo es el ordenamiento más un bucle de reintento.

**Compensaciones:** el ordenamiento estricto puede ser difícil cuando los patrones de acceso son dinámicos o abarcan tablas; un isolation más bajo arriesga anomalías (non-repeatable reads) sobre las que debes razonar. Los bucles de reintento deben ser **idempotentes** y acotados, o un conflicto caliente se convierte en una tormenta de reintentos. La prevención de deadlocks es en realidad disciplina de locks más un reintento acotado, no una única bala de plata.

El ciclo que debes romper

Estrategias

Perspectiva de la entrevista

Preguntas relacionadas