Questa è una proprietà di isolamento della transazione. C'è molto scritto a riguardo e consiglio vivamente la panoramica in Progettazione ad alta intensità di dati Applicazioni . L'ho trovata la descrizione più utile per migliorare la mia comprensione personale.
Il livello predefinito di Postgres è LEGGI COMMITTED che consente a ciascuna di queste transazioni simultanee di vedere un simile (stato di disponibilità dei fondi) anche se dovrebbero essere dipendenti.
Un modo per risolvere questo problema sarebbe contrassegnare ciascuna di queste transazioni come coerenza "SERIALIZABLE".
Ciò dovrebbe rafforzare la correttezza della tua domanda a un costo per la disponibilità, ovvero in questo caso la seconda transazione non sarà autorizzata a modificare i record e verrebbe rifiutata, il che richiederebbe un nuovo tentativo. Per un POC o un'applicazione a basso traffico questo è di solito un primo passo perfettamente accettabile in quanto è possibile garantire la correttezza per il momento.
Anche nel libro di cui sopra penso che ci fosse un esempio di come la disponibilità della maniglia di ATM. Consentono a questa condizione di gara e all'utente di eccedere se non è in grado di connettersi alla banca centralizzata, ma limitano il ritiro massimo per ridurre al minimo il raggio di esplosione!
Un altro modo architetturale per risolvere questo problema è portare le transazioni offline e renderle asincrone, in modo che ogni transazione invocata dall'utente venga pubblicata in una coda, quindi avendo un singolo consumatore della coda si evita naturalmente qualsiasi race condition. Il compromesso qui è simile, c'è un throughput fisso disponibile da un singolo lavoratore, ma aiuta a risolvere il problema di correttezza per ora :P
Il blocco tra le macchine (come l'utilizzo di redis su postgres/grpc) è chiamato blocco distribuito e ne è stato scritto molto https://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html
