サードパーティの支払いAPIの応答が成功した後のデータベースエラーの処理方法
私の場合の特定のシナリオにはPaypalが含まれていますが、他の外部システムも簡単に考えられます。
公式ドキュメントを含むインターネット上の多くの情報源によると、基本的なPaypal統合（たとえば、e-storeの場合）は次のようになります。
- Paypal APIを呼び出して、注文の支払いを実行します。
- 注文の詳細をデータベースに保存します。
支払いは成功したが、データベースに問題がある場合はどうなりますか？これは、ユーザーに請求したが記録できなかったことを意味します。
ユーザーに請求する前に注文を作成した場合、支払いが失敗し、未払いの注文がある可能性があります。
この問題をより適切に管理するために、私はこれを思いつきました：
- 支払いが保留されている注文を作成します。
- 支払いを実行します。
- 注文ステータスを更新します。
- 更新が失敗した場合は、再試行してください（DBの再試行）
- 再試行が失敗した場合は、何が失敗したのかを示すアラートをWebサイト管理者に送信し、この問題があったことをユーザーに通知します。
- メールが送信されなかった可能性もあります。その場合、ユーザーにエラーメッセージを送信して、大きなエラーが発生したことを伝え、できるだけ早く連絡してもらいたいと考えます（それ以外の場合はこのインシデントのため）まったく記録されません）。
残念ながら、ユーザーがこのメッセージを決して取得しないことも可能です。
基本的な流れのようですが、どう対処すればいいのか分かりません。どうすればよいですか？
このような失敗をビジネスロジックと再試行でカバーしようとするのは私の見解では間違いです。
あなたはいつでもあなたのロジックでカバーされていないシナリオを考えることができます。あなたのケースでは、ボックスのネットワークカードが機能していないため、DBの書き込みが失敗しました。したがって、電子メールを送信したり、ユーザーに応答したり、再試行しても役に立たないなどはありません。
代わりに、システムをトランザクション対応にしてみてください。すなわち。障害が発生する可能性のある場所であればどこでも、障害が発生したことがわかり、障害発生後に是正措置を講じることができます。
最悪の場合の例では、これは純粋に手動のロールバックになる可能性があります。したがって、もう一度例を挙げますと、beforeサードパーティにリクエストを送信し、「支払いリクエストxxxxを送信しようとしている」というログを書き込みますafterリクエストを取得します「支払い応答xxxを受け取りました」。
これで、コンピューターが開始ログと完了ログの間で完全にオフになった場合でも、ログを調べてエラーが発生したことを確認し、決済プロバイダーに電話をかけ、トランザクションxxxxについて尋ね、ユーザーに返金することができます。
Nb。
あなたのコメントから、あなたのソリューションの欠けている部分は、大まかに「モニタリング」と呼ばれているものであるようです。これは、すべてのログとメトリックを1か所にまとめるシステムです。例えば。 「ELKスタック」または同様のもの。このようなシステムを導入すると、ログの検索結果に基づいてさまざまなアラートを設定できます。すなわち
- システムXでエラーが記録された場合は、メールで通知してください
- 0900に60秒以上開いているすべてのトランザクションを示すレポートをメールで受け取る
2つのことを自問してみてください。何が悪いのでしょうか。支払いなしで製品を出荷する場合、または顧客が支払いを行い、出荷を受け取らない場合はどうでしょうか。そして、より可能性が高いのは、支払いが行われたり、受け入れられなかったりすることです。
私はjustで支払い要求を送信する前に、出荷を「支払われる可能性が高い」としてデータベースに書き込むことをお勧めします。支払い要求が通過するか拒否されると、データベースを更新します。ほとんどの場合、問題はありません。そうでない場合は、支払いが行われた可能性が高く、配送が正しい方法です。最悪の場合、顧客が支払いを行ったときに配送されないという可能性が高く評判を損なう間違いではなく、支払いを行わずに配送する可能性が低く、損害が少ない間違いを犯します。
このようなシナリオは、システムの外部のサービスを処理するときに、特にマイクロサービスアーキテクチャで多く発生します。あなたの場合、唯一の外部依存関係はPaypalです。私の意見では、あなたが提案したシナリオは大丈夫だと思われます：注文を保留中/待機中の支払いに設定し、Paypalに移動して、注文ステータスを更新します。特定のエラー処理の代わりに、データベース内の保留中の注文の数を示すダッシュボードがある、ある種の監視を実装できます。データベースがダウンしている場合、モニターがダウンしているため、問題があります。保留中の注文の数が多すぎる場合、何かが再び間違っている可能性があります。あなたが見ることができるもう一つのパターンは佐賀のパターンです。このパターンでは、プロセスが実行する必要のあるさまざまなステップの補正アクションを定義します。ただし、あなたのケースでは、Paypalがトランザクションのリバースに使用できるエンドポイントを提供していないと思いますので、これはあなたのケースでは役に立たないかもしれません。