製品注文の支払いは、レース中にどのように機能しますか？
これはかなり一般的な質問です。
シナリオ1
私は「ペン」という製品の数量が1です。2人のユーザーaとbが製品を購入しました。ユーザー「a」が「今すぐ購入」をクリックして支払い処理を開始し、支払いが完了すると、製品が作成され、数量をゼロに減らすと、ユーザーbには製品が「在庫なし」と表示されます。これはより巨視的な説明です。
シナリオ2
ユーザーaが支払いを行っており、その間にユーザーbが支払いをクリックし、支払いプロセスを続行しました。ユーザーa注文を完了し、数量はゼロになりましたユーザーb支払いを完了し、注文は失敗しました！
この問題はeコマースサイトでどのように管理されていますか？ユーザーが製品の支払いを進めると、数量がゼロに減り、注文が失敗した場合（支払いの失敗により）、他のユーザーが購入できるように数量が戻されますか？
この状態はどのように管理されますか？
これを処理するための多くの特定の戦略があります。一般的に言えば、ほとんどの場合、ある種のトランザクション（たとえば、db内、またはメモリ内のオブジェクトのロック）を使用するか、または補償戦略を使用することになります。多くのビジネスドメインは両方の組み合わせを使用していると思います。
コンサートドメインでは通常、予約を行うことができます。これは数分間有効であり、その間に注文を行うことができます。予約メカニズムはトランザクションを使用する場合があるため、在庫は無料から予約、購入、または無料に戻ります。予約が成功しない限り、請求は行われませんが、支払いが失敗した場合、すぐに在庫が戻されます。
航空会社もこれと同じ問題を抱えており、予約も使用していますが、通常、パートナー航空会社や旅行代理店がチケットを販売することを可能にするという点で、より広い分散コンピューティングの問題があります。その結果、彼らは最終的にフライトをオーバーブッキングする可能性があり、それから彼らは誰かが座席を放棄することに対して報酬を提供します。特に昔は、事前に一部の在庫を第三者の販売者に配布して、分散コンピューティングの問題を解決しようとしていました。
Eコマースサイトでは、アイテムを表示しているときに在庫不足の状況を通知しようとする場合があります。 eコマースサイトは、在庫がないときに支払いを行うことにより、失敗する場合があります（在庫がまったく間違っているか、一部のアイテムに対する需要が多すぎる）。次に、謝罪して支払いを返します。航空会社のように、彼らは不幸なユーザーにいくつかの追加の補償を提供するかもしれません。
基本的に、ビジネスでは、契約（つまり、購入）を期待していますが、それが失敗して対処する必要がある場合があります。故障は在庫にあるか、製品が輸送中に損傷/紛失したか、製品に欠陥がある可能性があります。これらの処理は、通常、補償戦略を利用します。事業運営の1つのポイントは、これらの戦略を調整することです（利益の最大化、顧客維持の最大化など）。