Loose CouplingとApplication Integration

注文APIは、下流の在庫更新サービスが数分停止しても注文受付を継続し、在庫更新は復旧後に処理できればよい。1つの論理ワーカープールが各注文を処理する。最も適切な統合方式はどれか。

注文確定イベントを請求、通知、分析の3システムへ配信する。各システムは同じイベントを独立して処理し、1つが停止しても他を止めず、停止したシステムは復旧後に未処理分を処理したい。最も適切な構成はどれか。

複数のAWSサービスと独自アプリケーションが業務イベントを発行する。イベントのsourceやdetailの内容に応じて異なる処理先へルーティングし、イベント発行側には各受信側を認識させたくない。最も適切なサービスはどれか。

注文処理は、在庫確保、支払い、承認待ち、出荷の複数ステップで構成される。条件分岐や待機があり、現在どの処理段階にあるかも管理したい。最も適切なサービスはどれか。

オンプレミスのActiveMQをAWSへ移行する。既存アプリケーションはOpenWireを使用しており、メッセージングコードの変更を最小限にしたい。最も適切な選択はどれか。

Amazon SQS標準キューで業務処理を疎結合化する。ワーカー障害や再配信を考慮した設計として正しいものを3つ選択してください。

同じ口座IDに対する更新は送信順に処理し、キュー自身が重複メッセージを導入しないことが重要である。一方、異なる口座IDは並行処理したい。最も適切な選択はどれか。

ある処理系は最大7日間停止する可能性がある。イベントはAmazon EventBridgeで分類している。停止中の対象イベントを失わず、復旧後にも未処理分へ追いつくための処理時間を確保し、処理系自身の速度ですべて処理する必要がある。最も適切な設計はどれか。

ECサイトでは、決済の承認結果は注文確定前に同期的に確認する必要がある。一方、注文確定後のメール通知と分析更新は数分遅れてもよく、これらの停止で注文受付を止めたくない。最も適切な設計はどれか。