サービス間通信の設計：REST vs メッセージキューの使い分け

概要

マイクロサービス間通信を設計するとき「REST か メッセージキューか」の選択は、システムの結合度・信頼性・スループット要件に直結する。それぞれの特性を理解したうえで、ユースケースに合わせて選択する。

詳細

比較表

観点	REST	メッセージキュー
通信スタイル	同期（リクエスト／レスポンス）	非同期（プロデューサー／コンシューマー）
結合度	密結合（相手が生きている必要あり）	疎結合（相手が落ちていてもOK）
レイテンシ	低い（即時応答）	高い（キュー経由）
スループット	受信側の処理能力に依存	バッファリングで吸収可能
再試行	呼び出し元が実装する必要あり	キュー側でリトライ制御できる
可視性	レスポンスで即確認	コンシューマー側でログ・監視が必要
実装コスト	低い	高い（インフラ整備が必要）

REST を選ぶべきケース

- ユーザーが結果をリアルタイムで必要とする
- 処理が即座に完了し、レスポンスを返す必要がある
- サービス間の依存関係が少なく、シンプルな構成で十分

例：

POST /api/orders        # 注文作成 → 即座にorder_idを返す
GET  /api/products/123  # 商品詳細取得

メッセージキューを選ぶべきケース

- 処理が重くて時間がかかる（メール送信、画像変換、レポート生成）
- 突発的なトラフィックを平滑化したい
- 複数のサービスが同じイベントを受け取る必要がある（ファンアウト）
- 処理の失敗をキューで安全にリトライしたい

例（Kafka / SQS / RabbitMQ）：

[注文サービス] → [order.created イベント] → [在庫サービス]
                                          → [通知サービス]
                                          → [分析サービス]

組み合わせパターン（現実的な設計）

クライアント → REST → APIゲートウェイ → REST → オーダーサービス
                                                    ↓
                                            メッセージキュー
                                           ↙      ↓       ↘
                                     在庫更新  メール通知  分析集計

なぜ重要か / いつ使うか

• システム設計面接の定番質問への回答を整理するとき
• 新機能の通信方式を設計するときの判断軸として
• 「なぜキューを使っているのか」をコードレビューで説明するとき