Publish/Subscribeは、情報を送りたい人（Publish）と受け取りたい人（Subscribe）を直接繋げず、掲示板のような場所を介してやり取りする仕組みです。例えば、学校の掲示板に「明日の運動会は雨天中止」と張り出す（Publish）と、それを見たい生徒（Subscribe）が見にくるイメージです。これにより、情報を送る側は誰が見るかを気にせず、受け取る側は必要な情報だけを選べるようになります。
面接官：Publish/Subscribeについて説明してください。
私：Publish/Subscribeモデルは、イベント駆動型アーキテクチャの中核をなすパターンの一つです。Pub/Subと略されることもあります。このモデルでは、パブリッシャー（Publisher）と呼ばれる情報の発信者と、サブスクライバー（Subscriber）と呼ばれる情報の受信者が、メッセージブローカーを介して間接的に通信します。パブリッシャーは特定のトピック（チャネル）にメッセージをPublishし、サブスクライバーはそのトピックをSubscribeすることで、関連するメッセージを受信します。
以前のプロジェクトで、マイクロサービス間の疎結合性を高めるためにPublish/Subscribeモデルを導入しました。具体的には、注文処理サービスが注文完了イベントをPublishし、在庫管理サービスと配送サービスがそのイベントをSubscribeすることで、注文完了後の処理を非同期的に行うようにしました。
これにより、注文処理サービスは在庫管理サービスや配送サービスの状況に依存せず、高速に注文を受け付けることが可能になり、全体的なシステムのスケーラビリティと可用性が向上しました。 また、新しいサービスを追加する場合も、既存のサービスに影響を与えることなく、必要なイベントをSubscribeするだけで済むため、開発の柔軟性も高まりました。
現役エンジニアによる深掘り解説
メリット
疎結合性: パブリッシャーとサブスクライバーが直接的に依存しないため、システム全体の結合度が低くなり、変更や拡張が容易になります。
スケーラビリティ: イベント処理を非同期的に行うため、各サービスは独立してスケールできます。
柔軟性: 新しいサブスクライバーを容易に追加できるため、システムの機能を柔軟に追加できます。
イベント駆動アーキテクチャ: 大規模で複雑なシステムにおいて、イベントをトリガーとした処理を効率的に実現できます。
デメリット
複雑性: メッセージブローカーの導入や設定が必要となり、システム全体の複雑性が増す可能性があります。
信頼性: メッセージブローカーの障害がシステム全体に影響を与える可能性があります。適切な可用性対策が必要です。
メッセージの保証: メッセージの配信保証（少なくとも1回、最大でも1回など）を考慮する必要があります。
モニタリング: 非同期処理のため、問題発生時の追跡やデバッグが難しくなることがあります。適切な監視体制が必要です。
⚠️ 面接突破のワンポイント
- 面接で聞かれた際は、具体的なメッセージブローカーの名前（Kafka, RabbitMQなど）を挙げ、それぞれの特徴や選定理由を説明できるように準備しましょう。
- Publish/Subscribeモデルだけでなく、他のメッセージングパターン（Queueなど）との比較を意識し、それぞれの適用場面を理解しておきましょう。
