サービスが生まれていますが、その価値を正しく提供するにはアプリケーションが正しく動かなければなりません。側ではユーザに適切なメッセージを表示しなければなりません。実際のところ、これらを厳密に実現するのは非常に困難ですが、アプリケーションにはこれら以上に複雑な問題が常につきまといます。アプリケーションはほとんどが分散システムの一形態です。クライアントとサーバや、サーバとデータベースがネットワークを介して接続されていればそれは分散システムと呼べますし、分散システム特有の問題と対峙しないといけないことを意味します。reliable)」という落とし穴が挙げられていますが、多くのアプリケーションはネットワークを無条件に信頼しています。エラーデータベースを持つシステムや、複数のバックエンドサービスがネットワークを介して接続されているようなシステムでは非常に様々なエラーが発生します。データベースへの負荷が高まったことにより書き込みを受け付けられなくなったり、データベースのクラッシュ、サーバとデータベース間の通信でネットワークエラーが発生し、書き込みを行えなかったりといった問題が挙げられます。バックエンドのサービスを提供するサーバがただ一つしかない場合、バックエンドは内部エラーを返すだけですが、サービスが複数になると途端に問題は複雑になります。データベースへ書き込みを行い、書き込んだデータオブジェクトをクライアントに返すようなシーケンスを考えてみます。以下のような図になります。いったエラーケースがあるか一つ考えてみましょう。データの書き込みに失敗し、エラーが返るようなケースはすぐに思いつくと思います。このケースを見るだけだとそこまで複雑には感じませんが、実際には以下のようなケースが起こりえます。クライアントにレスポンスを返す途中でネットワークエラーにより失敗として返ったこのようにさまざまなケースでエラーが起こることがわかるかと思います。ケースは、データベースに保存された結果とレスポンスの内容に不一致が生じてしまっています。この結果をユーザが見た場合、強い混乱を与えることになるでしょう。発生しうるため、列挙したエラーケースはほんの一部に過ぎません。リクエストを行うものとしてみると複雑さはさらに増加します。クライアントにレスポンスを返す途中でネットワークエラーにより失敗として返った先程の例では状態を保持しているデータベースが一つであり、その他のコンポーネントはステートレスでしたが、状態が複数のデータベースに保存されるようになるとデータ不整合の問題がかならず発生します。データが書き込まれておらず、データ不整合が発生しています。本来であれば、リクエストが失敗として返ったのであればデータは一切書き込まれておらず、リクエストが成功として返ったのであれば両方のデータベースにデータが書き込まれているという状態であるべきです。する必要が出てきます。書き込み処理を行う際にデータ不整合の修復を行う仕組みです。実現する最もメジャーな手法はリトライを行うことです。リクエストのリトライを行うことで解決し、正常なレスポンスを受け取れる可能性があります。当然ながらクライアントエラーなどのリトライ不可能なエラーはリトライしても意味がないため、バックエンドサービスにはリトライ可能なエラーと不可能なエラーを明確に区別し、ハンドリングする責務があります。多重リクエストと同一性しかし、タイムアウト等のエラーでは、バックエンドの処理が成功した直後にクライアントがタイムアウトと判断してしまい、リトライを行ってしまうようなケースが発生することがあります。リクエストをしてしまうため、二重にリクエストされることになります。これがリソースの作成、例えばブログでいう記事の投稿であればまったく同じ記事が二重に投稿されてしまうことになります。そのくらいであればユーザは許容できるかもしれませんが、これが決済システムであれば多重決済となり深刻な問題となります。ものなのかを判別する手段はありません。リトライを行いつつ、多重にリクエストが処理されるのを防ぐ方法はいくつかあります。一致していれば同一のリクエストとみなす方法があります。生成の責務は常にクライアントが持つことになります。v4、ユニークな入力など、特に制約はありません。持つリクエストを受け取っていた場合、冪等性を担保できるように処理を行います。リクエストであれば、冪等性チェックを行い、すでに記事が作成されていた場合はデータベースに保存されているデータをもとにレスポンスを生成し返却します。同一であるため新たに記事の作成は行いません。このようにシステム全体で冪等性が担保された設計になっており、各バックエンドサービスがそれらのエラーを適切にハンドリングし、リトライ可能なレスポンスステータスを返していれば、そのクライアントはリトライを行うことにより正常に処理できるようになります。トランザクションの状態管理バックエンドサービス内で冪等性を担保した実装を行うにあたって、どのように冪等性のチェックを行えばいいのか、という問題があります。