金融サービス企業がマイクロサービスアーキテクチャへの移行を計画しています。現在のモノリシックシステムは 1 日あたり 1,000 万トランザクションを処理し、各トランザクションはデータ整合性が極めて重要です。新アーキテクチャの要件は以下の通りです。 ①各マイクロサービスは独自のデータストアを持つ（Database per Service パターン）。 ②分散トランザクション間のデータ整合性を保証する（最終的整合性は許容するが、ビジネスルール違反は許容しない）。 ③監査ログとして全トランザクションの変更履歴を保持する。 ④サービス間の疎結合を維持する。 ⑤障害発生時に自動的にロールバックまたは補償トランザクションを実行する。 ⑥ピーク時のスループットは 1 秒あたり 500 トランザクション。設計として最も適切なアーキテクチャパターンと AWS サービスの組み合わせはどれですか？
Step Functions による Orchestration ベースの Saga パターンはトランザクション全体のフロー・状態・補償処理を一元管理でき、複雑な金融トランザクションの可視化と障害時の補償トランザクション自動実行に最適です。 選択肢A の Aurora Global Database はクロスリージョン読み取りレプリカ機能であり分散トランザクション管理を提供せず、API Gateway 経由の同期 REST 通信は密結合を生み疎結合要件を満たしません。 選択肢B の Choreography ベースでは多段階トランザクションの全体状態追跡と補償管理が困難で、EventBridge Pipes は複雑な補償ワークフローのオーケストレーションには適しません。 選択肢D の2フェーズコミット（2PC: Two-Phase Commit）はマイクロサービスのアンチパターンであり、中央コーディネーターへの依存が単一障害点となって可用性を低下させます。