C'est une propriété de l'isolation des transactions. Il y a beaucoup d'écrits à ce sujet et je recommande vivement la présentation dans Designing Data-Intensive Candidatures . J'ai trouvé que c'était la description la plus utile pour améliorer ma compréhension personnelle.
Le niveau postgres par défaut est LIRE COMMITTED qui permet à chacune de ces transactions simultanées de voir un état similaire (fonds disponibles) même si elles devraient être dépendantes.
Une façon de résoudre ce problème serait de marquer chacune de ces transactions comme une cohérence "SERIALIZABLE".
Cela devrait renforcer l'exactitude de votre application au détriment de la disponibilité, c'est-à-dire que dans ce cas, la deuxième transaction ne sera pas autorisée à modifier les enregistrements et serait rejetée, ce qui nécessiterait une nouvelle tentative. Pour un POC ou une application à faible trafic, il s'agit généralement d'une première étape parfaitement acceptable, car vous pouvez garantir l'exactitude pour le moment.
Toujours dans le livre référencé ci-dessus, je pense qu'il y avait un exemple de la façon dont les guichets automatiques gèrent la disponibilité. Ils autorisent cette condition de concurrence et permettent à l'utilisateur de tirer à découvert s'il est incapable de se connecter à la banque centralisée mais limitent le retrait maximum pour minimiser le rayon de souffle !
Une autre façon architecturale de résoudre ce problème consiste à mettre les transactions hors ligne et à les rendre asynchrones, de sorte que chaque transaction invoquée par l'utilisateur soit publiée dans une file d'attente, puis en ayant un seul consommateur de la file d'attente, vous évitez naturellement toute condition de concurrence. Le compromis ici est similaire, il y a un débit fixe disponible à partir d'un seul travailleur, mais cela aide à résoudre le problème d'exactitude pour le moment :P
Le verrouillage sur plusieurs machines (comme l'utilisation de redis sur postgres/grpc) s'appelle le verrouillage distribué et a beaucoup écrit à ce sujet https://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html
