Pub/Sub 發佈訂閱模式：從遊戲通知到雲端架構 Pub/Sub Pattern: From Game Notifications to Cloud Architecture
Pub/Sub 是雲端架構裡最常被問到的設計模式之一。用遊戲場景來解釋，比任何教科書都直覺。
什麼是 Pub/Sub？
發佈／訂閱（Publish/Subscribe）是一種訊息傳遞模式。你可以把它想成遊戲裡的活動通知系統：
- 官方後台發佈一則「限時活動開始」
- 所有有訂閱通知的玩家同時收到
更經典的例子是打怪完成後的連鎖反應——殺死 100 隻怪物這個單一事件，同時觸發：
- 獲取經驗值
- 完成每日任務
- 計算怪獸掉落寶物率
這三件事由三個獨立的訂閱者各自處理，發布者只負責發出訊息，完全不管後面有幾個人在接。無論是 15 位還是 1500 位訂閱者，Publish 的邏輯一個字都不用改。
四大優點
1. 服務完全解耦（Decoupling）
發布者和訂閱者不需要知道彼此的存在，甚至不需要同時上線。其中一個服務當機，不會造成連鎖崩潰，系統容錯能力大幅提升。
2. 非同步處理（Asynchrony）
傳統 API 呼叫：發布端要等待接收端回覆。
Pub/Sub：發布者丟出訊息後立刻去做下一件事，訊息由中介者（Broker）保管。玩家 Alice 離線也沒關係——等她上線，再收到今日的 520 限時活動通知即可。
3. 水平擴展性（Scalability）
流量暴增時，不需要修改發布者的邏輯，只要獨立增加訂閱者伺服器的數量，就能平行處理大量工作負載。
4. 即時廣播與多重接收
發布者發送一次，中介者把訊息分發給所有訂閱者。非常適合多個團隊或應用程式需要同時依賴同一個資料來源的場景。
Push vs Pull：兩種接收模式
訊息到了之後，訂閱者怎麼拿到它？有兩種選擇：
Push 模式（推）
有新訊息，伺服器主動塞給你。
適用場景：射擊遊戲中，敵人開槍，伺服器必須立刻把傷害數據推到你的畫面，延遲一秒就死了。
Pull 模式（拉）
訂閱者定期主動詢問：「有我的新訊息嗎？」
適用場景：遊戲世界排行榜。不需要每秒同步，只在玩家打開排行榜分頁的那一刻，才向伺服器拉取最新排名。
GCP Pub/Sub 架構示意
[ 遊戲官方後台 ] ──(Publish)──> [ GCP Pub/Sub Topic ]
│
┌────────────────────┴────────────────────┐
▼ ▼
[ Subscription: Alice ] [ Subscription: Bob ]
│ │
(Push 或 Pull 訊息) (Push 或 Pull 訊息)
▼ ▼
[ Alice 的手機 / 伺服器 ] [ Bob 的手機 / 伺服器 ]Topic 是訊息的「頻道」，Subscription 是每個訂閱者各自的「收件匣」。同一則訊息，每個 Subscription 都能獨立收到一份，互不干擾。
延伸發現：電子報大量寄信也適用
訂閱電子報統一發送信件，同樣可以用 Pub/Sub 架構處理。不過這裡有個實務上的坑：
Google 對單一寄信者有每日 5000 封的上限，超過就可能被鎖定，或信件一律落入垃圾信匣。
實務做法是串接第三方郵件發送服務（如 SendGrid、Mailgun），讓 Pub/Sub 負責觸發，由專業的郵件服務負責實際投遞——既能確保到達率，也不會觸碰 Google 的限制。
Pre-sales 視角
當客戶說「我們想在使用者完成某個動作後，同時觸發好幾個後端流程」，Pub/Sub 幾乎是標準答案。重點不只是推薦這個服務，而是能解釋清楚：
- 為什麼解耦對他們的業務有價值（某個服務壞掉不會拖垮整體）
- Push 還是 Pull 比較適合他們的場景（即時性 vs 成本考量）
- 擴展時要改哪裡（只加訂閱者，不動發布者）
把架構說清楚，才是真正的售前價值。
Pub/Sub is one of the most commonly asked-about design patterns in cloud architecture. A game scenario makes it more intuitive than any textbook.
What Is Pub/Sub?
Publish/Subscribe is a messaging pattern. Think of it like an in-game event notification system:
- The official server publishes a "Limited-time event starting now" message
- All subscribed players receive it simultaneously
A more classic example is the chain reaction after defeating monsters — killing 100 monsters is a single event that simultaneously triggers:
- Gaining experience points
- Completing daily quests
- Calculating monster drop rates
These three things are handled independently by three separate subscribers. The publisher only sends the message — it doesn't care how many people are receiving it. Whether there are 15 or 1,500 subscribers, the publish logic doesn't change at all.
Four Key Advantages
1. Full Decoupling
Publishers and subscribers don't need to know each other exist, or even be online at the same time. If one service goes down, it won't cause a cascading failure — dramatically improving fault tolerance.
2. Asynchronous Processing
Traditional API calls: the publisher must wait for the subscriber to respond.
Pub/Sub: the publisher sends the message and immediately moves on. The broker holds the message. If Alice is offline, she'll receive the notification when she comes back online.
3. Horizontal Scalability
When traffic spikes, you don't modify the publisher's logic — just add more subscriber servers independently to handle the load in parallel.
4. Real-time Broadcast & Multi-recipient Delivery
The publisher sends once, and the broker distributes to all subscribers. Perfect when multiple teams or applications need to simultaneously depend on the same data source.
Push vs Pull: Two Delivery Modes
Push Mode
New message? The server actively delivers it to you.
Use case: In a shooter game, when an enemy fires, the server must immediately push damage data to your screen — a one-second delay means death.
Pull Mode
Subscribers periodically ask: "Any new messages for me?"
Use case: In-game leaderboards. No need to sync every second — only fetch the latest rankings when the player opens the leaderboard tab.
GCP Pub/Sub Architecture
[ Game Backend ] ──(Publish)──> [ GCP Pub/Sub Topic ]
│
┌────────────────────┴────────────────────┐
▼ ▼
[ Subscription: Alice ] [ Subscription: Bob ]
│ │
(Push or Pull message) (Push or Pull message)
▼ ▼
[ Alice's phone / server ] [ Bob's phone / server ]
A Topic is the message "channel." A Subscription is each subscriber's individual "inbox." Each Subscription independently receives its own copy of the same message.
Pre-sales Perspective
When a client says "we want to trigger several backend processes simultaneously after a user completes an action," Pub/Sub is almost always the answer. The key isn't just recommending the service — it's being able to explain clearly:
- Why decoupling is valuable for their business (one service failing won't drag down everything else)
- Whether Push or Pull better suits their scenario (real-time vs. cost considerations)
- What changes when scaling (just add subscribers, don't touch the publisher)
Explaining the architecture clearly is the real pre-sales value.