これは、トランザクション分離のプロパティです。それについて書かれたものはたくさんあり、データ集約型の設計で概要を強くお勧めしますアプリケーション 。個人的な理解を深めるのに最も役立つ説明だと思いました。
デフォルトのpostgresレベルは
これに対処する1つの方法は、これらの各トランザクションを"SERIALIZABLE"整合性としてマークすることです。
これにより、可用性を犠牲にしてアプリケーションの正確性が強化されます。つまり、この場合、2番目のトランザクションはレコードの変更を許可されず、拒否され、再試行が必要になります。 POCまたはトラフィックの少ないアプリケーションの場合、現時点で正確性を確保できるため、これは通常、完全に許容できる最初のステップです。
また、上記の本には、ATMが可用性を処理する方法の例があったと思います。これらは、この競合状態を許容し、中央バンクに接続できない場合にユーザーがオーバードローすることを許可しますが、最大引き出しを制限して爆風半径を最小化します！
これに対処するもう1つのアーキテクチャ上の方法は、トランザクションをオフラインにして非同期にすることです。これにより、ユーザーが呼び出した各トランザクションがキューに公開され、キューの単一のコンシューマーを持つことで、競合状態を自然に回避できます。ここでのトレードオフは、1人のワーカーから利用できる固定スループットがあることと似ていますが、現時点での正確性の問題に対処するのに役立ちます：P
分散ロックと呼ばれるマシン間でのロック（postgres / grpc全体でのredisの使用など）には、かなりの量が書かれています https://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html