Como você previne deadlocks com milhares de transações concorrentes?

Question

IT Interview Practice · Accepted Answer

**Adquira locks em uma ordem global consistente, mantenha as transações curtas, reduza o isolation onde for seguro, e faça retry do perdedor quando um deadlock ainda acontecer.** Um deadlock é um ciclo: a transação A segura a linha 1 e espera pela linha 2, enquanto B segura a linha 2 e espera pela linha 1 — nenhuma pode prosseguir, então o DB mata uma.

## O ciclo que você deve quebrar

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

## Estratégias

- **Ordenação consistente de locks.** Se toda transação sempre travar linhas na mesma ordem (ex. primary key ascendente), um ciclo é impossível — A e B ambas pegam a linha 1 primeiro, então uma simplesmente espera. Esta é a maior alavanca. Um bug clássico: uma transferência de dinheiro que trava contas na ordem `(from, to)` deadlocka com a transferência reversa; sempre trave por `min(id), max(id)`.
- **Transações curtas.** Segure locks pelo menor tempo possível — faça validação, chamadas de rede e leituras **antes** do `BEGIN`, depois trave, escreva e `COMMIT` rápido. Transações longas alargam a janela para ciclos e esperas de lock.
- **Reduza o isolation onde for seguro.** `SERIALIZABLE` pega mais locks/range locks e deadlocka mais; `READ COMMITTED` (padrão do Postgres) trava menos. Use o isolation mais fraco que ainda atenda à correção.
- **Retry no deadlock.** Deadlocks são transientes. Capture o erro de deadlock (Postgres `40P01`, MySQL `1213`) e faça retry da transação inteira com um pequeno backoff. Alguma contenção é inevitável em escala, então o retry é uma rede de segurança, não um substituto para a ordenação.

## Perspectiva de entrevista

O entrevistador verifica se você sabe que deadlocks são **prevenidos por design, não apenas capturados**. Nomear "retry" sozinho é uma resposta fraca — a ótima resposta lidera com **ordenação consistente de locks** e **transações curtas**, depois adiciona retry para o residual. Uma armadilha comum: assumir que o app deve detectar deadlocks; na prática o **DB detecta o ciclo e aborta uma vítima** por você — seu trabalho é ordenação mais um loop de retry.

**Trade-offs:** ordenação estrita pode ser difícil quando os padrões de acesso são dinâmicos ou abrangem tabelas; isolation mais baixo arrisca anomalias (non-repeatable reads) que você deve raciocinar. Loops de retry devem ser **idempotentes** e limitados, ou um conflito quente vira uma tempestade de retries. Prevenção de deadlock é na verdade disciplina de lock mais um retry limitado, não uma única bala de prata.

O ciclo que você deve quebrar

Estratégias

Perspectiva de entrevista

Perguntas relacionadas