TERM 031
Pub / Sub
発行側と購読側を分離して、イベントを配る
Pub/Sub（Publish / Subscribe）は、送信者（Publisher）がトピック（Topic）へメッセージを送信し、そのトピックを購読している複数の受信者（Subscriber）がそれぞれ受け取る非同期通信の仕組みです。送信側は受信側の台数や所在を意識する必要がありません。
送信側と受信側を分離してメッセージを配る方式の全体像。
CONTENTSこの記事の目次＋
01 — DEFINITION
Pub / Subとは
何か
Pub/Sub（Publish / Subscribe）は、送信者（Publisher）がトピック（Topic）へメッセージを送信し、そのトピックを購読している複数の受信者（Subscriber）がそれぞれ受け取る非同期通信の仕組みです。送信側は受信側の台数や所在を意識する必要がありません。
02 — HOW IT WORKS
仕組みを
3段階で見る
細部へ入る前に、入力から結果までの役割を順番に捉えます。
イベントを発行
発生したイベントや事実をトピックへメッセージとして送信する。
→購読ごとに配る
メッセージ基盤が、登録された各サブスクリプションへメッセージを複製・配送する。
→独立して処理
各サブスクライバーが自身の処理速度や再試行ポリシーに合わせてメッセージを受信する。
Pub / Subを理解するときの、最小の処理単位です。
03 — ESSENTIALS
押さえるべき
3つの要点
名前だけでなく、この3点の関係まで理解すると実装へつなげやすくなります。
発行先の名前
Publisherが受け手を知らずにイベントを送る接点です。
購読ごとの設定
未読メッセージの配送位置、再試行間隔、保持期間などを購読者ごとに管理します。
配送保証
少なくとも一回などの性質を理解し、受け手を冪等にします。
04 — REAL WORLD EXAMPLE
注文確定イベントを複数サービスへ配る
在庫、メール、分析が同じ注文確定を別々に利用します。
- 01
注文サービスがorder.createdイベントを発行する
- 02
3つのサブスクリプションへイベントメッセージを並行配送する
- 03
在庫・メール・分析の各サービスが独立して処理を行う
05 — WATCH OUT
理解するときの
注意点
便利な仕組みほど、守備範囲と失敗の前提を明確にします。
順序を暗黙に期待しない
必要なら順序キーを使うか、データ側の版で新旧を判断します。
イベントスキーマの互換性を管理する
既存の購読サービス（Subscriber）を壊さないよう、フィールドの追加方法やスキーマのバージョニングをあらかじめ計画します。
IN ONE SENTENCE
Pub / Subとは？
送信側と受信側を分離してメッセージを配る方式。