グローバル展開するeコマース企業が、新しいオーダー管理プラットフォームをAWS上に構築しています。要件は以下の通りです。 【現在の課題】 - 1日に平均500万件の注文処理が必要で、ピーク時には通常の10倍のトラフィックが発生する - 注文データは複数のマイクロサービス（在庫、決済、配送、通知）が非同期で処理する必要がある - 決済処理は最低1回の配信保証が必要で、重複処理を防がなければならない（冪等性の確保） - 通知サービスは決済完了後に即時にトリガーされる必要があるが、通知失敗は注文処理全体に影響してはならない - 在庫サービスは時折メンテナンスで停止するが、その間も注文は受け付け続ける必要がある 【追加要件】 - 各マイクロサービスは独立してスケールできること - 処理失敗したメッセージは最大3回リトライ後、デッドレターキュー（DLQ）に送る - イベントの順序は決済サービスのみが保証される必要がある - コスト最適化のため、処理量に応じた従量課金モデルを採用する これらすべての要件を満たすアーキテクチャとして最も適切なものはどれですか？
SNS+SQSファンアウトパターンは各要件を満たす最適解です。SQS FIFOは決済の順序保証と冪等性（MessageDeduplicationId）を提供します。標準SQSは在庫サービスのメンテナンス中もメッセージを保持し、可視性タイムアウトとDLQで最大3回リトライを実現します。通知はEventBridgeで決済完了後のみトリガーされ、失敗しても他サービスに影響しません。LambdaとECSは需要に応じた自動スケールと従量課金を実現します。 選択肢A の Kinesisはストリーミングデータのリアルタイム処理向きでキュー用途には過剰です。 選択肢C の Step Functionsは同期的なワークフロー向けで要件の非同期パターンに不適です。 選択肢D の Amazon MQはマネージドサービスですがEC2ベースのコンシューマーではコスト最適化と独立スケールの要件を満たしにくいです。