O que causa uma condição de corrida, e como você acha uma que só aparece em produção?

Uma condição de corrida acontece quando duas threads ou requests tocam estado mutável compartilhado e o resultado depende do timing. O formato clássico é ler, modificar, escrever sem segurar um lock nos três passos. Para achar uma em produção, procure estado que é checado e depois usado numa ação, adicione logging correlacionado em volta dessa sequência, reproduza sob concorrência real em vez de num teste unitário, e deixe restrições do banco pegarem a violação.

Uma corrida precisa de duas coisas: estado mutável compartilhado, e dois caminhos chegando nele ao mesmo tempo. Quase toda que eu já depurei tem o mesmo formato, uma checagem seguida de uma ação com um intervalo no meio. Ler o saldo, decidir que é suficiente, escrever o saldo novo. Dois requests se intercalam e o número fica errado. Achar isso em produção é principalmente aceitar que você não chega no repro clicando. Eu escrevo um script que dispara o mesmo request umas duzentas vezes concorrentemente, porque a janela pode ter dois milissegundos de largura. Aí eu logo com um request id dos dois lados da leitura e da escrita, para conseguir ver a intercalação na linha do tempo. Para a correção eu tento mover o invariante para o banco em vez da aplicação: um update com um where no valor esperado, ou uma restrição única, para o banco impor. Locks em nível de aplicação só funcionam se todo escritor passar pelo seu código, e mais cedo ou mais tarde um não vai passar.