Esta é uma propriedade de isolamento de transação. Há muito escrito sobre isso e eu recomendo a visão geral em Designing Data Intensive Aplicativos . Achei que era a descrição mais útil para melhorar minha compreensão pessoal.

O nível padrão do postgres é READ COMMITTED o que permite que cada uma dessas transações simultâneas veja um semelhante (estado de fundos disponíveis), mesmo que elas devam ser dependentes.

Uma maneira de resolver isso seria marcar cada uma dessas transações como consistência "SERIALIZABLE".

Isso deve impor a veracidade do seu pedido a um custo de disponibilidade, ou seja, neste caso a segunda transação não terá permissão para modificar os registros e seria rejeitada, o que exigiria uma nova tentativa. Para um POC ou um aplicativo de baixo tráfego, esse geralmente é um primeiro passo perfeitamente aceitável, pois você pode garantir a correção agora.

Também no livro mencionado acima, acho que havia um exemplo de como os caixas eletrônicos lidam com a disponibilidade. Eles permitem essa condição de corrida e o usuário pode sacar a descoberto se não conseguir se conectar ao banco centralizado, mas limita a retirada máxima para minimizar o raio de explosão!

Outra maneira arquitetural de resolver isso é colocar as transações offline e torná-las assíncronas, de modo que cada transação invocada pelo usuário seja publicada em uma fila e, em seguida, tendo um único consumidor da fila, você naturalmente evita quaisquer condições de corrida. A compensação aqui é semelhante, há uma taxa de transferência fixa disponível de um único trabalhador, mas ajuda a resolver o problema de correção no momento:P

Bloquear entre máquinas (como usar redis em postgres/grpc) chamado de bloqueio distribuído e tem uma boa quantidade escrita sobre isso https://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html