注文処理システムで、注文受付APIと在庫更新処理を疎結合にしたいです。在庫更新処理が一時的に停止しても注文メッセージを失わず、後で処理できる構成はどれですか？

解説

SQSを使うと、注文受付と在庫更新を非同期・疎結合にできます。処理側が一時停止してもメッセージをキューに保持できます。

選択肢ごとの解説

実務での使いどころ

Amazon SQS は、メッセージ送信側（プロデューサー）と受信側（コンシューマー）を時間的・物理的に分離するためのフルマネージド型キューサービスである。注文受付 API がリクエストを受けた時点で SQS にメッセージを投入し、在庫更新ワーカーが別プロセスとして自分のペースでメッセージを取り出して処理する構成にすれば、在庫更新側が一時的に停止していてもメッセージは最大 14 日間キューに保持される。標準キュー（Standard Queue）は順序保証なし・少なくとも 1 回配信、FIFO キューは順序保証・厳密に 1 回処理を提供する。 代替案として SNS（pub/sub）や EventBridge（イベントバス）もあるが、SNS は通知のファンアウト用途、EventBridge はルーティング・スキーマ管理用途であり、ワーカーがメッセージを「取りに行く」ポーリング型のジョブキューには SQS が最も素直に当てはまる。注意点としては、コンシューマー側で可視性タイムアウト（Visibility Timeout）を処理時間より長く設定すること、処理失敗時の再試行回数を超えたメッセージを退避させる Dead Letter Queue（DLQ）を必ず設定することの 2 点が運用上の定石である。 SAA-C03 では、疎結合（decoupling）・非同期処理・耐障害性というキーワードが出題文に含まれる場合、SQS が第一候補となる。誤答としては「ワーカー側で同期 HTTP 呼び出し」「DynamoDB に直接書き込み」「EC2 を Auto Scaling で増やす」など、疎結合化以外の論点にすり替える選択肢が混ぜられる。SNS と SQS の使い分け（通知配信か、ワーカーキューか）も頻出論点である。