失敗に耐えるSMM API連携を設計する

どのAPI連携も、最初のバージョンはハッピーパスを前提にします。リクエストを送れば、レスポンスが返り、注文が発行される、と。本番環境は、そうではないことを教えてくれます。ネットワークは切れ、エンドポイントはタイムアウトし、最も危険な失敗は曖昧なものです。接続が切れる前に成功したかもしれないし、しなかったかもしれないリクエストです。その曖昧さのために設計することが、仕事のすべてです。

冪等性が核となる防御です。各注文リクエストに一意のキーを付け、サーバーがそのキーの繰り返しを、新しい操作ではなく同じ操作として扱うようにします。こうすれば、タイムアウト後の再試行は安全です。元のリクエストが通っていれば、二重の課金ではなく既存の注文が返ってきます。これがなければ、どの再試行もあなたの残高を賭けたギャンブルになります。

その上に、バックオフ付きの再試行を重ねます。一時的なエラー（429のレート制限、503、ネットワークのリセット）は、すぐに叩き続けるのではなく、遅延を増やしながら上限を設けて再試行すべきです。恒久的なエラー（400の不正なリクエスト、残高不足のレスポンス）は、素早く失敗させて人に届けるべきです。それらを再試行しても、時間を無駄にし、本当の問題を覆い隠すだけだからです。

最後に、照合しましょう。すべてのリクエストとレスポンスを、その冪等キーと注文IDとともに記録し、あなたの記録をパネルの注文状態と突き合わせる定期的なジョブを走らせること。照合は、パネル上では成功したのに、あなたの側で記録に失敗した注文を捕まえるものです。SocialGOのAPIが一貫した注文IDと状態を返すのは、まさにこのループを組みやすくするためです。それが、信頼できる自動化と、付きっきりで面倒を見る自動化との差なのです。