はじめに
更新系APIの状態不整合の解決策 リトライの課題として、更新リクエストのリトライで複数のトランザクションを生成させないための設計の肝をメモする。
同一RequestID受信時のidempotency(冪等性)のレスポンス返却
idempotencyの設計思想によるAPIは、同じRequestIDを受信した場合、最初に受信したRequestIDを同じレスポンスを返却する。（下のシーケンスでは、レスポンス値にOKに加えてTransactionID,TimeStampを例として記載）
課題としてサーバBのデータベースの性能を考慮する必要がある。RequestIDの同一チェックに加えて、同一の場合、過去のレスポンス値をデータベース検索するため処理が重くなる。
サーバBにとって性能に課題がある一方、サーバAは実装が容易となる。
正常ケースのシーケンス
よくあるバグ
リトライ時にRequestID=002でリクエストして、サーバBに2件トランザクションが生成されて、件数不整合が発生する。
| トランザクション | サーバAの状態 | サーバBの状態 |
|---|---|---|
| RequestID001 | 不明 | 処理済み |
| RequestID002 | 処理済み | 処理済み |
業務エラー
結論
サーバAが設定する一意なパラメータ(ここではRequestIDと定義した)によりサーバBに重複してトランザクションが生成されることを防止できる。
API仕様が、次のようになっているか確認すること
- リトライ時に同一のRequestIDを設定する
- 同一RequestIDに対してidempotencyのレスポンスが返却される
(再掲)課題としてサーバBのデータベースの性能を考慮する必要がある。RequestIDの同一チェックに加えて、同一の場合、過去のレスポンス値をデータベース検索するため処理が重くなる。