EC サイトが AWS Step Functions を使って「在庫確認 → 決済処理 → 配送手配」という注文処理ワークフローをオーケストレーションしています。決済処理ステップでは外部決済プロバイダーを呼び出す Lambda 関数を実行しており、一時的なネットワークエラーによる失敗と、カード残高不足などの恒久的なビジネスエラーの両方が発生します。一時的エラーは自動でリトライし、恒久的エラーは在庫を戻す補償処理ステップへ遷移させる必要があります。最も適切な実装はどれですか？
Step Functions の各ステートには Retry と Catch を宣言的に定義できます。Retry では MaxAttempts・IntervalSeconds・BackoffRate（指数バックオフの倍率）をエラー名（例: Lambda.ServiceException）ごとに設定してリトライを自動化できます。Catch では別のエラー名（例: カスタム例外 CardDeclinedError）を捕捉して補償ステップ（在庫戻し）へ遷移できます。Lambda 関数自体はシンプルに保ちつつ、ワークフローレベルで弾力的なエラーハンドリングが宣言的に実現できます。 選択肢AのLambda 内で SQS 再送は機能しますが、ワークフロー全体の状態管理が分散・複雑化し、Step Functions の実行状態と SQS キューの状態が乖離するリスクがあります。 選択肢CのEventBridge から再起動は Step Functions 実行を最初から再起動するため、完了済みの在庫確認ステップが重複実行され、二重引き当てなど整合性の問題を引き起こします。 選択肢DのDLQ は Lambda が非同期呼び出しされる場合に有効ですが、Step Functions からの同期呼び出し（RequestResponse）では DLQ は機能しません。