Dit is een eigenschap van transactie-isolatie. Er is veel over geschreven en ik zou het overzicht in Designing Data-Intensive ten zeerste aanbevelen Toepassingen . Ik vond het de meest nuttige beschrijving om mijn persoonlijke begrip te verbeteren.
Het standaard postgres-niveau is LEES TOEGANG waardoor elk van deze gelijktijdige transacties een soortgelijk beeld kan zien (status beschikbaar geld), ook al zouden ze afhankelijk moeten zijn.
Een manier om dit aan te pakken is om elk van deze transacties te markeren als "SERIALIZABLE" consistentie.
Dit zou de juistheid van uw aanvraag moeten afdwingen ten koste van de beschikbaarheid, dat wil zeggen dat in dit geval de tweede transactie de records niet mag wijzigen en zou worden afgewezen, wat een nieuwe poging zou vereisen. Voor een POC of een applicatie met weinig verkeer is dit meestal een perfect acceptabele eerste stap, omdat je op dit moment zeker kunt zijn van correctheid.
Ook in het boek waarnaar hierboven wordt verwezen, denk ik dat er een voorbeeld was van hoe ATM's met beschikbaarheid omgaan. Ze zorgen voor deze race-conditie en de gebruiker kan rood staan als ze geen verbinding kunnen maken met de centrale bank, maar beperken de maximale opname om de explosieradius te minimaliseren!
Een andere architecturale manier om dit aan te pakken, is door de transacties offline te halen en ze asynchroon te maken, zodat elke door de gebruiker aangeroepen transactie in een wachtrij wordt gepubliceerd, en door een enkele gebruiker van de wachtrij te hebben, vermijdt u natuurlijk race-omstandigheden. De afweging hier is vergelijkbaar, er is een vaste doorvoer beschikbaar van een enkele werknemer, maar het helpt wel om het correctheidsprobleem op dit moment aan te pakken:P
Vergrendelen op verschillende machines (zoals het gebruik van redis via postgres/grpc) wordt gedistribueerde vergrendeling genoemd en er is veel over geschreven https://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html