本文是跨 vendor migration playbook、cross-link 到 AWS SQS 跟 Google Pub/Sub。這是一個 跨雲 managed-to-managed 遷移：兩端都是 cloud-managed、運維負擔都低、但 資料拓樸 跟 消費抽象 不同 — SQS 是 region-scoped 的單一 pull queue、Pub/Sub 是 global topic + 多個 first-class subscription。主結構走 operational redesign hybrid（Type C）、額外為 components / data topology 兩個高維度抽獨立段。

SQS 跟 Pub/Sub 不是同一種訊息抽象

SQS 跟 Pub/Sub 都是 cloud-managed 非同步訊息服務、都解「解耦 producer / consumer、不自管 broker」這個問題、application 程式碼裡都是「發訊息、收訊息、處理完確認」的形狀。從這層看兩者可互換、遷移像是換 SDK。

差別在 消費抽象 跟 資料拓樸。SQS 的核心實體是 queue：一條 region-scoped 的訊息隊列、訊息被一個 consumer 領走（in-flight）就對其他 consumer 隱形、處理完 DeleteMessage 就消失。要讓同一筆事件送給多個下游、SQS 端的做法是在 SNS 前面 fan-out、再各接一條 SQS queue。Pub/Sub 的核心實體是 topic + subscription 兩層：topic 收訊息、subscription 是 first-class 的消費端點、一個 topic 可掛 N 個 subscription、每個 subscription 各自維護消費進度、fan-out 是模型內建而不是外接。

這個差別決定了遷移的形狀。如果原系統只是「一條 queue、一群 worker 競爭領取」、那 Pub/Sub 端是「一個 topic、一個 pull subscription」、對位乾淨、application 改動小。如果原系統靠 SNS-to-many-SQS 做扇出、那 Pub/Sub 端是「一個 topic、多個 subscription」、整個 fan-out 拓樸要重畫、這不是換 SDK、是重設計訊息流。先判斷自己屬於哪一種、再決定 playbook 的重量。

為什麼會跨雲遷這條路徑

跨雲從 SQS 遷到 Pub/Sub 的 driver 跟同雲 vendor 切換不同、通常不是「Pub/Sub 比 SQS 好」、而是 整體 workload 的重心移到 GCP：

1. 資料平台落在 GCP：下游分析走 BigQuery、streaming 走 Dataflow、容器跑 Cloud Run。事件如果留在 AWS、每筆都要跨雲搬到 GCP 才能進 BigQuery、跨雲 egress 費用跟延遲都是常態成本。把訊息層也移到 Pub/Sub、事件可以用 BigQuery subscription 直接落地、省掉中間搬運。
2. 需要 global topic、不想管 region：SQS queue 綁 region、跨 region 要自己複製或在前面架路由。Pub/Sub topic 沒有 region 概念、publish 進去全球可訂閱、多區域服務的事件分發是 first-class。
3. fan-out 從外接變內建：原本靠 SNS + 多條 SQS 維護的扇出拓樸、在 Pub/Sub 是「一個 topic 掛多個 subscription」、少一層 SNS、扇出關係在 subscription 列表一覽。

這三條 driver 都假設 重心已經或即將在 GCP。如果系統長期紮根 AWS、只為了「換個 queue」跨雲、會付出跨雲 IAM 重對位、雙雲計費、跨雲網路延遲的代價、ROI 通常不成立。遷移前先確認 driver 是 workload 重心轉移、不是單純偏好。

結構為什麼是 operational hybrid 加兩個高維度獨立段

寫這篇前先跑 diff dimension audit、6 維評級如下：

主導維度是 operational model（跨雲身份與監控全換）、所以主結構走 Type C operational redesign hybrid。但 components 跟 data topology 也是 High — 不是把它們塞進 operational 段就能講清楚的、消費抽象從「一條 queue」變「topic + 多 subscription」是讀者最容易踩雷的地方。按 migration 方法論的 multi-axis 規則、高維度抽成獨立段補充、不硬塞進單一 type 標籤。所以本篇結構是：operational 對位主軸 + 「消費抽象重設計」獨立段（components / topology 軸）+ 跨雲特有的 IAM 與網路段。

Operational 對位：機制名詞換、語意要逐一確認

跨雲遷移最容易出錯的環節、是 找到語意相近的功能、卻假設行為一致。SQS 跟 Pub/Sub 多數機制都有對位、但每一組都有行為差、找得到對應功能只是第一步。下表先給對照、後面逐項展開語意陷阱。

Visibility timeout → ack deadline

Visibility timeout 跟 ack deadline 都回答同一個問題：consumer 領走訊息後、多久沒確認就視為失敗、把訊息重新投遞。語意對位成立、但兩端的數字與延長機制不同。

SQS visibility timeout 預設 30 秒、上限 12 小時、consumer 要延長就主動呼叫 ChangeMessageVisibility。Pub/Sub ack deadline 預設 10 秒、上限 600 秒（10 分鐘）、而且 client library 預設會 自動 在背景延長 deadline（lease management）。這個自動延長是最容易踩到的差異：在 SQS 端習慣「設一個夠長的 visibility timeout、處理完再 delete」、搬到 Pub/Sub 如果只把 ack deadline 設成 600 秒上限、卻沒意識到 client library 在背景幫忙延長、長任務的行為會跟預期不同；反過來、如果關掉自動延長又設了預設 10 秒、處理稍久就重投。對位的正確做法是先理解 client library 的 lease 行為、再決定 ack deadline 跟 MaxAckPending、而不是把 SQS 的 timeout 數字直接搬過去。

maxReceiveCount / redrive → dead-letter topic

兩端都用「重試 N 次仍失敗就隔離」防止 poison message 阻塞 pipeline、但隔離後的容器不同。SQS 的 DLQ 是另一條 queue、用 maxReceiveCount 控制門檻、修好下游後用 redrive policy 把訊息放回原 queue。Pub/Sub 的 dead-letter topic 是另一個 topic、用 subscription 的 max delivery attempt 控制門檻、超過就 publish 到 DLT。

差別在重處理路徑。SQS redrive 是把 DLQ 訊息搬回 main queue、是一個 queue-to-queue 的搬移動作。Pub/Sub 的 DLT 是 topic、要重處理得在 DLT 上再開一個 subscription 來消費、沒有內建的「放回原 topic」按鈕。Mercari item feed 的案例就是用 DLT 把重試多次仍失敗的訊息隔離、讓後續訊息優先處理、同時把 topic 當突發流量的 load-leveling buffer。從 SQS 搬過來時、redrive 的心智模型要換成「DLT 是一個獨立 topic、重處理是另開 subscription」、不是「按一個按鈕放回去」。設定 DLT 還需要給 Pub/Sub service account 對 DLT 的 publisher 權限跟對原 subscription 的 subscriber 權限、漏設會讓訊息卡住不進 DLT。

Long polling → streaming pull

這一組不是等價對位、是機制不同。SQS long polling 是 consumer 發一個 ReceiveMessage 請求、最多等 20 秒、有訊息就回、沒有就空回、本質仍是 輪詢、只是把空輪詢的頻率降下來省 cost。Pub/Sub 的 pull 在 client library 預設是 streaming pull：consumer 跟 Pub/Sub 建一條長連線、訊息一到就推過來、不是 consumer 反覆問。

對位時不要把 long polling 的「WaitTimeSeconds 20 秒」翻譯成某個 Pub/Sub 參數 — 沒有對應參數、因為機制不同。要關注的是 flow control：streaming pull 因為訊息會主動推來、要用 MaxOutstandingMessages / MaxAckPending 控制同時在處理的訊息量、否則 consumer 會被一次塞太多訊息壓垮。SQS 端「一次拉最多 10 條」的批次節流、在 Pub/Sub 端變成 flow control 設定。Spotify autoscaling 的案例揭露了相關陷阱：下游失敗時 consumer 不 ack 仍持續消耗 CPU、autoscaling 反而把資源越拉越高 — autoscale 訊號要看處理成功率、不是 backlog 加 CPU。

IAM policy → Service Account

跨雲遷移裡、身份模型是 重對位 而不是改語法的部分。SQS 的存取控制是 IAM policy（identity-based、掛在 user / role）加 queue policy（resource-based、掛在 queue）兩層、cross-account 靠這兩層互動。Pub/Sub 是 GCP IAM role（publisher / subscriber / viewer 等）加 Service Account、push subscription 要用 Service Account 認證到目標 endpoint。

兩套身份模型沒有自動轉換工具、要逐條重畫：誰能 publish 對應誰有 topic 的 publisher role、誰能消費對應誰有 subscription 的 subscriber role。跨雲場景還多一層 — 如果遷移期 AWS 端的服務要 publish 到 GCP 的 topic、得用 workload identity federation 或 service account key、讓 AWS 的工作負載拿到 GCP 身份。這部分沒有 case 可引、依 GCP 官方 IAM 文件加最小權限原則設計：每個 service account 只給它實際需要的 role、不要為了遷移方便給 broad role 再說以後收緊、那個「以後」通常不會來。

CloudWatch → Cloud Monitoring

監控訊號要重建、不是改名。SQS 在 CloudWatch 看 ApproximateNumberOfMessagesVisible（queue 深度）跟 ApproximateAgeOfOldestMessage（lag）。Pub/Sub 在 Cloud Monitoring 看 num_undelivered_messages（backlog）跟 oldest_unacked_message_age（最老未確認訊息年齡）。語意相近、但 alarm 邏輯要重寫、而且 Pub/Sub 的 backlog 數字要配合 subscription 維度看 — 同一個 topic 的不同 subscription 各自有 backlog、一個堵住不代表全部堵住。遷移時要把原本對 queue 深度的告警、改成對每個 subscription 的 backlog 與 age 告警。

消費抽象重設計：從一條 queue 到 topic 加多 subscription

這是 components 跟 data topology 兩個高維度的核心、也是從 SQS 搬到 Pub/Sub 最需要重新畫圖的地方。SQS 的世界裡、一條 queue 對應一群競爭領取的 worker；要扇出就在前面架 SNS、SNS 後面接多條 SQS、每條 queue 各一群 worker。Pub/Sub 把這個拓樸壓平：一個 topic 收訊息、掛多少個 subscription 就有多少條獨立的消費流、每個 subscription 各自記進度、彼此不影響。

重設計從盤點現有拓樸開始。先列出：哪些是「單一 queue、一群 worker」的簡單情境、哪些是「SNS fan-out 到多條 SQS」的扇出情境。簡單情境對位乾淨 — 一個 topic、一個 pull subscription、原本競爭領取的 worker 改成同一個 subscription 的多個 consumer、Pub/Sub 自動把訊息分給它們。扇出情境要把 SNS + 多 SQS 換成「一個 topic + 多 subscription」、原本每條 SQS queue 變成一個 subscription、SNS 那一層消失。

扇出情境裡有個方向相反的陷阱要避免：不要把「多個下游」誤設計成「多個 consumer 共用一個 subscription」。同一個 subscription 的多個 consumer 是 競爭 關係、訊息只會給其中一個 — 那是負載分攤、不是扇出。要每個下游都收到完整一份、就要每個下游一個 獨立 subscription。這跟 SQS 端「一條 queue 一個下游、扇出靠 SNS 複製」的直覺方向一致、但實體換了：在 SQS 是多條 queue、在 Pub/Sub 是多個 subscription。畫遷移圖時、SQS 的每條 fan-out queue 一對一映射到 Pub/Sub 的一個 subscription、不要合併。

Application 重設計範例：SQS receive-delete 換成 Pub/Sub pull-ack

 1// SQS 端：long polling receive、處理完 DeleteMessage
 2svc := sqs.NewFromConfig(cfg)
 3for {
 4    out, _ := svc.ReceiveMessage(ctx, &sqs.ReceiveMessageInput{
 5        QueueUrl:            &queueURL,
 6        MaxNumberOfMessages: 10,
 7        WaitTimeSeconds:     20, // long polling
 8    })
 9    for _, m := range out.Messages {
10        process(m.Body)
11        svc.DeleteMessage(ctx, &sqs.DeleteMessageInput{
12            QueueUrl:      &queueURL,
13            ReceiptHandle: m.ReceiptHandle,
14        })
15    }
16}

1// Pub/Sub 端：streaming pull、處理完 Ack、用 flow control 節流
2sub := client.Subscription("orders-sub")
3sub.ReceiveSettings.MaxOutstandingMessages = 100 // flow control、取代「一次拉 10 條」
4err := sub.Receive(ctx, func(ctx context.Context, msg *pubsub.Message) {
5    process(msg.Data)
6    msg.Ack() // 取代 DeleteMessage；client library 在背景自動延長 ack deadline
7})

差異：

• SQS 主動輪詢（ReceiveMessage 迴圈）→ Pub/Sub 回呼模型（Receive 把訊息推進 callback）
• SQS DeleteMessage → Pub/Sub msg.Ack()、語意都是「確認處理完、別重投」
• SQS WaitTimeSeconds 控制輪詢等待 → Pub/Sub MaxOutstandingMessages 控制 flow control
• SQS 一次最多 10 條的批次上限 → Pub/Sub 沒有這個上限、改用 flow control 設同時在途量
• ack deadline 的延長在 SQS 要主動 ChangeMessageVisibility、在 Pub/Sub 由 client library 自動處理

application 邏輯的商業處理部分（process 函式）多數可保留、改動集中在收訊息的框架跟確認語意、估計 20-40% 程式碼。

Production 故障演練

Case 1：fan-out 設計成共用 subscription、下游各收到一部分

徵兆：把原本 SNS fan-out 到 3 條 SQS 的拓樸搬到 Pub/Sub、為了省事建一個 topic + 一個 subscription、讓 3 個下游服務都連這個 subscription。上線後發現每個下游只收到大約三分之一的訊息、不是各收完整一份。

根因：同一個 subscription 的多個 consumer 是負載分攤關係、Pub/Sub 把訊息分給其中一個 consumer、不是每個都送。這對應到 SQS 端「一條 queue 多個 worker 競爭領取」的行為、但被誤用在需要扇出的場景。SQS 端的扇出靠 SNS 複製訊息到多條 queue、那個複製動作在 Pub/Sub 應該由「多個 subscription」承擔、不是多個 consumer 共用一個 subscription。

修法：

1. 每個下游一個獨立 subscription：3 個下游就建 3 個 subscription 掛同一個 topic、每個各收完整一份
2. 遷移圖一對一映射：SQS 的每條 fan-out queue 對應一個 Pub/Sub subscription、不合併
3. 負載分攤跟扇出分開設計：同一下游要多 worker 分攤、是同一 subscription 多 consumer；不同下游各收一份、是多 subscription

Case 2：ack deadline 沿用 SQS 數字太短、長任務反覆重投

徵兆：SQS 端 visibility timeout 設 5 分鐘跑得好好的、搬到 Pub/Sub 隨手把 ack deadline 設成預設或一個小數字、結果處理時間稍長的訊息被反覆重投、同一筆訊息處理多次、下游出現重複副作用。

根因：Pub/Sub ack deadline 預設 10 秒、上限 600 秒、跟 SQS visibility timeout 上限 12 小時差很多。如果關掉 client library 的自動 lease extension、又把 ack deadline 設小、處理時間一超過就被判定失敗重投。SQS 的「設一個夠長的 timeout」直覺搬過來不適用、因為 Pub/Sub 的上限低很多、且延長機制是 client library 自動做。

修法：

1. 理解 client library 的 lease 行為：多數 client library 預設會背景自動延長 ack deadline 到處理完、優先依賴這個而不是手動設超長 deadline
2. 長任務拆短或改架構：單筆處理超過 10 分鐘上限的、考慮拆成多階段或把長任務移出訊息處理路徑
3. 下游做 idempotency：跟 SQS 一樣、Pub/Sub 是 at-least-once、重投本來就會發生、下游用 message ID 去重才是根本解

Case 3：FIFO 順序需求對位到 ordering key、吞吐落差超出預期

徵兆：原系統用 SQS FIFO queue + MessageGroupId 保證同一群訊息順序處理、搬到 Pub/Sub 啟用 ordering key 對位、上線後吞吐比預期低很多、且某些情境順序仍亂。

根因：SQS FIFO 跟 Pub/Sub ordering key 都提供順序、但取捨點不同。SQS FIFO 同時給「順序」跟「5 分鐘去重窗口」、吞吐受限（每 MessageGroupId 串行）。Pub/Sub ordering key 給「同一 key 的訊息按 publish 順序送達」、但要 publish 端跟 subscription 端都正確設定（publish 要設 ordering key、subscription 要 enableMessageOrdering）、漏一邊順序就不保證；而且啟用 ordering 後同一 key 串行、吞吐同樣受限。把 FIFO 的「去重 + 順序」一包功能、誤以為 ordering key 也一包提供、是落差來源。

修法：

1. 拆開「順序」跟「去重」兩個需求：Pub/Sub ordering key 只管順序、去重要 application 端自己用 message ID 做
2. publish 跟 subscription 兩端都設 ordering：缺一邊順序不保證、遷移檢查清單要把兩端都列上
3. 重新評估是否真需要全域順序：FIFO 常被過度使用、很多場景只需要 per-entity 順序、用 ordering key 按 entity 分 key、比強制全域串行吞吐高很多

Case 4：跨雲遷移期雙雲都在跑、egress 成本與延遲被低估

徵兆：漸進 cutover 期間 AWS 跟 GCP 兩邊都在處理訊息、為了對帳把訊息在兩雲之間搬、月底帳單跨雲 egress 費用遠超預估、且跨雲呼叫的尾延遲拖慢端到端處理。

根因：SQS 在 AWS region 內、Pub/Sub 在 GCP、遷移期的 dual publish 或對帳如果讓資料反覆跨雲、每一筆出 AWS 的訊息都計 egress 費。跨雲不只是錢、跨雲網路的延遲跟抖動比同雲高、放在同步處理路徑上會放大尾延遲。同雲 vendor 切換沒有這個維度、跨雲遷移必須把它列進成本模型。

修法：

1. 縮短雙雲並行窗口：dual publish 的對帳期越短越省、設明確的並行截止日、不要無限期雙跑
2. 對帳用抽樣不用全量搬運：驗證一致性用抽樣比對 message ID / count、不要把所有訊息都搬到對面雲比對
3. 生產者就近落點：遷移後讓 producer 直接 publish 到 Pub/Sub、不要繞 AWS 再跨雲、消除穩態的跨雲 egress

Case 5：dead-letter topic 權限沒配齊、毒訊息卡住不進 DLT

徵兆：subscription 設了 dead-letter topic 跟 max delivery attempt、預期重試超限的訊息進 DLT、實際上毒訊息一直在原 subscription 反覆重投、DLT 是空的、後續訊息被堵。

根因：Pub/Sub 要把訊息送進 DLT、是由 Pub/Sub 的 service account 代為 publish 到 DLT topic；同時它也要對原 subscription 有 subscriber 權限才能 ack 掉原訊息。這兩個權限漏任一個、forwarding 到 DLT 就失敗、訊息卡在原 subscription。SQS 端 DLQ 是 queue 屬性、不需要額外給 service 權限、所以這個跨雲差異容易被漏掉。

修法：

1. 配齊 DLT 雙權限：給 Pub/Sub service account 對 DLT topic 的 publisher role、跟對原 subscription 的 subscriber role
2. 遷移後做毒訊息演練：故意 publish 一筆會失敗的訊息、確認它真的在 max attempt 後進 DLT、不是卡在原 subscription
3. 監控 DLT backlog：DLT 開一個 subscription 監控其 num_undelivered_messages、確認毒訊息有被導流且有人處理、對照 Mercari DLT 案例的設計

漸進 cutover：dual publish 加雙消費對帳

跨雲遷移風險高、不適合一次切換、走漸進 cutover 把可逆邊界拉長：

1. Phase 0：拓樸盤點 — 列出所有 SQS queue、標記哪些是單一 queue、哪些是 SNS fan-out、各自映射到 Pub/Sub 的 topic / subscription 結構
2. Phase 1：Pub/Sub 端建好對位資源 — 建 topic / subscription / DLT、配齊 IAM 與 service account、重建 Cloud Monitoring 告警、application 寫好 Pub/Sub consumer 但先不收流量
3. Phase 2：dual publish — producer 同時 publish 到 SQS 跟 Pub/Sub、兩邊 consumer 都跑、Pub/Sub 端的處理結果先寫到隔離區或標記、不影響正式下游
4. Phase 3：雙消費對帳 — 抽樣比對兩邊處理的訊息 ID 與數量、確認 Pub/Sub 端沒漏、沒重複到無法接受的程度、ack deadline / fan-out / ordering 行為都符合預期
5. Phase 4：流量切換 — 對帳通過後、把正式下游切到 Pub/Sub 端、SQS 端轉成備援、保留一段觀察期可回切
6. Phase 5：下線 SQS — 觀察期穩定後停掉 dual publish、移除 SQS 資源、消除穩態跨雲 egress（這是不可逆階段、不要在對帳沒過時提前做）

對帳期是這套流程的核心保險、也是 Case 4 跨雲成本的來源 — 對帳用抽樣、並行窗口設明確截止日、平衡「驗證信心」跟「雙雲成本」。

Capacity / cost 對照

判讀：穩態成本兩者量級相近、真正的成本差在 遷移期 — dual publish 雙雲並行加跨雲對帳搬運是一次性高峰、不是穩態。把這段窗口縮短、是控制跨雲遷移成本的關鍵、不是去比 SQS 跟 Pub/Sub 的單價。扇出重度的系統遷到 Pub/Sub 後、少掉 SNS 那一層、扇出的計費結構也變簡單。

整合 / 下一步

遷移後事件可直接落 GCP 資料平台

遷到 Pub/Sub 的一個結構性好處、是事件可以用 BigQuery subscription 直接寫進 BigQuery、不需要再寫 Dataflow pipeline 搬運；或用 Cloud Storage subscription 批次落 GCS。這正是「workload 重心在 GCP」這條 driver 的回報 — 事件層跟資料平台同雲、省掉跨雲搬運。這也是評估是否該跨雲遷移時、要放進 ROI 的一邊。

跟 Kafka 遷移的結構對照

結論：SQS → Pub/Sub 不是 paradigm shift（兩端都是 cloud-managed 訊息服務、可收斂成單一目標）、是 operational redesign 為主、消費抽象重設計為輔的跨雲遷移；結構由主導差異維度（operational）決定主軸、高維度（components / topology）抽獨立段補充。

相關連結

• Source / target vendor：AWS SQS / Google Pub/Sub
• 平行 vendor：Kafka / RabbitMQ / NATS
• 平行 migration playbook：Kafka ↔ NATS
• 引用案例：3.C64 Mercari Item Feed DLT / 3.C61 Spotify autoscaling
• Methodology：Migration Playbook 寫作方法論
• 上游概念：0.3 非同步選型 / 6.12 idempotency / replay

本文是 Google Cloud Pub/Sub overview 的 implementation-layer deep article。選型層（Pub/Sub vs Kafka / SQS）見 overview；本文只處理「決定用 Pub/Sub 後，subscription 與 ack 怎麼設」。Pub/Sub 是 managed SaaS、無法本機 docker 驗證，本文 config 依 Pub/Sub 官方文件 與下列 production case、最後檢查日 2026-06-16；引數與計費以官方為準。

push vs pull 不是實作偏好

把 Pub/Sub 的 subscription 設成 push 還是 pull，常被當成「看團隊習慣」的實作選擇。但它其實是一個關於下游容量的判讀。差別在流量控制權在誰手上：push subscription 由 Pub/Sub 主動把訊息 HTTP POST 到目標 endpoint——流量節奏由 Pub/Sub 決定，尖峰時瞬間打過來；pull subscription 由 consumer 主動拉，要拉多少、多快由 consumer 自己控制。

Mercari 的 LINE 整合把這個判讀講得很具體：Braze webhook 進來轉成 Pub/Sub event，下游要呼叫 LINE API——而 LINE API 有 RPS 限制。如果用 push，Pub/Sub 會把訊息瞬間打到 worker、worker 再打 LINE、直接超過 LINE 的 RPS 上限。所以他們用 pull subscription，worker「精確控制每秒處理訊息數」來對齊 LINE 的限制。這個案例揭露的原則是——push vs pull 不是實作偏好，是「下游能不能承受 push 的流量衝擊」的判讀：下游有速率限制、處理能力有限、或需要平滑流量，就走 pull 自我節流。

本文展開 subscription 模型、ack deadline、flow control 與 dead-letter topic——這些決定了訊息怎麼被可靠地、以下游能承受的速度消費。

核心概念：subscription、ack deadline 與 flow control

Pub/Sub 把「topic（發布）」跟「subscription（訂閱）」分開，可靠消費的旋鈕都在 subscription 上。

一個 topic、多個 subscription、各自獨立。發布者發到 topic，每個 subscription 收到一份完整的訊息流、各自維護消費進度。這天然支援 fanout（多個服務各建一個 subscription）。Mercari 的另一個案例還揭露 topic 的雙重角色——它同時是「dispatch」跟「load-leveling buffer」，突發流量先進 topic 緩衝、consumer 按自己節奏消化。

ack deadline 是 Pub/Sub 版的可見性逾時。consumer 收到訊息後，有一段 ack deadline 來處理並 ack。在 deadline 內沒 ack，Pub/Sub 重新投遞（at-least-once）。跟 SQS visibility timeout 同樣是雙邊風險：太短→處理中就重投、太長→失敗後恢復慢。處理中可用 modifyAckDeadline（client library 通常自動 lease extension）延長。

flow control 限制 client 端同時持有的未 ack 量。pull subscription 的 client library 可設 max_outstanding_messages / max_outstanding_bytes——consumer 最多同時持有多少未 ack 訊息。這是 consumer 端自我節流的旋鈕，避免一次拉太多撐爆自己或下游。Mercari 對齊 LINE RPS 靠的就是這層控制。

dead-letter topic（DLT）給毒訊息出口。subscription 設 dead-letter policy（maxDeliveryAttempts + dead-letter topic）後，重投超過上限的訊息被轉到 DLT，不再阻塞後續。Mercari item feed 正是「重試多次仍失敗送 DLT、後續訊息優先處理」——避免 poison message 卡住 pipeline。

配置：subscription + ack deadline + DLT（依官方文件）

Pub/Sub 是 managed、以下 gcloud 依官方文件（未本機 docker 驗證、引數以官方為準）：

 1# 1. 建 topic + dead-letter topic
 2gcloud pubsub topics create orders
 3gcloud pubsub topics create orders-dlt
 4
 5# 2. pull subscription：ack deadline + dead-letter policy
 6gcloud pubsub subscriptions create orders-worker \
 7  --topic=orders \
 8  --ack-deadline=60 \
 9  --dead-letter-topic=orders-dlt \
10  --max-delivery-attempts=5
11
12# 3. consumer 端 flow control（client library、以 Python 為例、概念跨語言一致）
13#    flow_control = FlowControl(max_messages=100, max_bytes=10*1024*1024)
14#    subscriber.subscribe(sub_path, callback=handle, flow_control=flow_control)
15#    handle 內：處理成功 message.ack()、失敗 message.nack()
16
17# push subscription（僅當下游能承受 Pub/Sub 主動推的流量時）：
18# gcloud pubsub subscriptions create orders-push \
19#   --topic=orders --push-endpoint=https://my-svc/handler --ack-deadline=60

判讀：

• 下游有 RPS 限制 / 處理能力有限 → pull + flow control（self-throttle，Mercari 模式）
• 下游能吸收推送尖峰、要 serverless 簡單 → push
• ack-deadline 略高於處理時間；長任務靠 client library 的 lease extension
• max-delivery-attempts + DLT 給毒訊息出口

Production 故障演練

Case 1：用 push、下游被瞬間流量打爆

徵兆：流量尖峰時下游 endpoint 5xx 暴增、或下游的第三方 API 回 429（rate limited），訊息大量重投惡化。

根因：用 push subscription，Pub/Sub 把訊息瞬間 POST 到 endpoint，超過下游（或下游依賴的外部 API）的處理 / 速率上限。正是 Mercari LINE 要避開的情形。

修法：

1. 下游有速率限制改用 pull subscription + flow control，由 consumer 自我節流
2. flow control 的 max_outstanding_messages 對齊下游能承受的並發
3. push 只用在下游能吸收推送尖峰的場景
4. push 場景下游要自己擋（rate limit / 佇列），不能假設 Pub/Sub 會幫你平滑

Case 2：ack deadline 太短、訊息處理中就被重投

徵兆：同一則訊息被處理多次，尤其處理較慢時；訂閱的 redelivery 指標偏高。

根因：ack deadline 設得比處理時間短，訊息在處理途中 deadline 到期、Pub/Sub 重投。跟 SQS visibility timeout 太短同類。

修法：

1. ack deadline 設成略高於處理時間 p99
2. 用 client library 的自動 lease extension（modifyAckDeadline）處理長尾任務
3. 消費端冪等——at-least-once 本來就可能重投（見 6.12 idempotency）
4. 監控 redelivery 率，偏高代表 deadline 偏短或處理變慢

Case 3：沒設 DLT、毒訊息一直重投阻塞

徵兆：某則訊息一直失敗、一直被重投，後續訊息處理被拖慢。

根因：subscription 沒設 dead-letter policy。處理失敗（nack 或沒 ack）的訊息一再重投、沒有上限與出口，毒訊息反覆消耗 consumer。

修法：

1. 設 dead-letter policy（max-delivery-attempts + DLT），重投達上限轉 DLT
2. DLT 是另一個 topic，要有處理 / 告警流程（Mercari「送 DLT、後續訊息優先處理」）
3. max-delivery-attempts 平衡暫時性失敗重試與毒訊息隔離
4. 對照 SQS redrive：兩者都是 managed 原生 DLQ/DLT、比自建省事

Case 4：flow control 沒設、consumer 一次拉太多撐爆

徵兆：consumer 記憶體暴增 / OOM，或一次拉太多把下游打爆。

根因：pull subscription 沒設 flow control，client library 預設可能持有大量未 ack 訊息，consumer 端記憶體與下游壓力失控。

修法：

1. 設 max_outstanding_messages / max_outstanding_bytes 限制同時持有量
2. 對齊 consumer 處理能力與下游容量（Mercari 對齊 LINE RPS）
3. 監控 consumer 記憶體與未 ack 數，調 flow control 參數
4. flow control 是 pull 自我節流的核心，不設等於放棄背壓

Case 5：誤用 ordering key、吞吐受限

徵兆：開了 message ordering 後吞吐明顯下降、特定 ordering key 的訊息處理變慢。

根因：Pub/Sub 的順序保證是 per-ordering-key 的——同一個 ordering key 的訊息嚴格按序、必須序列處理（前一則 ack 才處理下一則）。把所有訊息塞同一個 ordering key 等於序列化整條流、吞吐崩。

修法：

1. ordering key 用細粒度（per-entity，如 per-user），讓不同 key 可並行
2. 不需要嚴格順序的就別開 ordering（預設無序、吞吐高）
3. 評估順序需求的真實範圍——多數場景只需 per-entity 順序，不是全域
4. 嚴格全域順序 + 高吞吐有本質衝突，重新審視需求或走 Kafka 的 partition 模型

Capacity / cost 邊界

Pub/Sub 的容量判讀（managed、無 broker 運維）：

撞牆後的路由判斷：

• 需要長期保留 + 任意 replay：Pub/Sub 有 retention（可設、seek 到時間點）但事件流長期 replay + 生態走 Kafka。
• 嚴格全域順序 + 高吞吐：Pub/Sub ordering 是 per-key 序列化，全域順序高吞吐走 Kafka partition 設計。
• 不在 GCP 生態：Pub/Sub 綁 GCP，跨雲走 Kafka / NATS 或對應雲的 managed（SQS）。
• 複雜 routing（topic exchange 式）：Pub/Sub 是 topic→subscription 扇出，複雜 routing 規則走 RabbitMQ exchange。

整合 / 下一步

push/pull 判讀與 ack 是 Pub/Sub 可靠消費的核心，它跟其他議題交織：

• 跟 3.4 consumer design：push/pull、ack deadline、flow control 是 consumer 設計的具體選項。
• 跟 6.12 idempotency / replay：at-least-once + 重投要求消費冪等。
• 跟 SQS visibility timeout：ack deadline 對應 visibility timeout、DLT 對應 redrive，兩個 managed queue 的可靠消費模型高度對位、可對照閱讀。
• 跟 webhook buffer 模式：Pub/Sub topic 當 load-leveling buffer（Mercari）對應 SQS Twilio webhook buffer——把不可控的外部 webhook 流量先緩衝再按自己節奏消化。

相關連結

• 上游 vendor 頁：Google Cloud Pub/Sub
• 對照 vendor：AWS SQS visibility timeout、RabbitMQ DLQ
• 對應案例：3.C65 Mercari LINE flow control、3.C64 Mercari item feed DLT
• 上游概念：3.4 consumer design

本文是 Google Cloud Pub/Sub overview 的 implementation-layer deep article。Overview 回答「Pub/Sub 該不該選、跟 Kafka / SQS 差在哪」；本文回答「ordering key 怎麼設、DLT 怎麼擋 poison message、schema 怎麼守契約，各自踩哪些坑」。閱讀前可先讀 overview 的 ordering / DLT / schema 各段建立 context。

文中 gcloud 指令的語法以 Pub/Sub emulator 實機驗證（topic / subscription / schema / ordering key / DLT / push 各操作均跑通），標準版的雲端配額、IAM 與計費行為依官方文件。

三道治理共用同一個交付骨架

Pub/Sub 的 ordering key、dead-letter topic、schema enforcement 看似三個獨立功能，實際都掛在同一個交付骨架上：subscription 是消費進度的 first-class 抽象、訊息經 ackDeadline 控制重投、失敗訊息經投遞次數計數決定去留。理解這個骨架之後，三道治理只是骨架上的三個切面 — ordering 切的是「投遞順序」、DLT 切的是「投遞次數上限」、schema 切的是「投遞前的內容守門」。

這條骨架跟 Kafka 思路不同。Kafka 的消費進度綁在 consumer group + partition offset；Pub/Sub 的 topic 是 first-class，subscription 才是 consumer 抽象，一個 topic 可以掛 N 個 subscription、各自有獨立進度與獨立的 ackDeadline / DLT / ordering 設定。同一份 event 流，A subscription 可以開 ordering 嚴格有序、B subscription 可以不開 ordering 換吞吐，互不影響。

把這三道治理寫進一篇的理由是：它們在 production 會互相牽制。Ordering key 開了之後 DLT 的隔離行為會變（有序流裡一則 poison message 會卡住整把 key 的後續訊息）；schema enforcement 擋下的不相容 publish 不會進 DLT（根本沒進 topic）。分開讀三個官方頁面看不到這層耦合。

subscription 是 first-class：ackDeadline 與 extension

subscription 承擔「這個消費者讀到哪、還有多少沒 ack」的責任。每則訊息投遞給 subscriber 後，Pub/Sub 啟動一個 ackDeadline 倒數；倒數內收到 ack 就移除訊息、倒數結束沒收到 ack 就重投。預設 ackDeadline 是 10 秒、上限 600 秒。

 1# subscription 的 ackDeadline 預設 10 秒、retention 預設 7 天
 2gcloud pubsub subscriptions describe demo-sub
 3# ackDeadlineSeconds: 10
 4# messageRetentionDuration: 604800s   # 7 天
 5
 6# 建 subscription 時可顯式設更長的 ackDeadline 與更短的 retention
 7gcloud pubsub subscriptions create cfg-sub \
 8  --topic=demo-topic \
 9  --ack-deadline=120 \
10  --message-retention-duration=3d
11# ackDeadlineSeconds: 120
12# messageRetentionDuration: 259200s   # 3 天

ackDeadline 是一道「處理時間預算」。設太短，處理還沒完訊息就被重投，consumer 會收到重複；設太長，consumer crash 後訊息要等滿 deadline 才重投，延遲拉高。長任務不靠把 ackDeadline 一次設到 600 秒解決，而是靠 ack deadline extension：consumer 在處理中週期性發 modifyAckDeadline 把單則訊息的 deadline 往後延，處理完才 ack。

1# pull 一則但不 auto-ack，拿到 ackId
2ACKID=$(gcloud pubsub subscriptions pull demo-sub --limit=1 --format='value(ackId)')
3
4# 處理中動態延長這則訊息的 ackDeadline 到 300 秒
5gcloud pubsub subscriptions modify-message-ack-deadline demo-sub \
6  --ack-ids="$ACKID" \
7  --ack-deadline=300

實務上不手動發 modifyAckDeadline，而是用 client library 的自動 lease 管理：client 在背景對 outstanding 訊息週期性續約，直到 application code 回 ack / nack。這跟 SQS 的 visibility timeout 語意類似 — 都是「訊息正在被處理、暫時別重投」的租約 — 但 Pub/Sub 是 per-message lease + client 自動續約，SQS 是 per-receive visibility window + 手動 ChangeMessageVisibility。

ackDeadline 的陷阱在 batch 邊界。client library 常以 batch 為單位 pull，但 ackDeadline lease 是 per-message。若 application 把整個 batch 當一個工作單元處理、處理時間超過單則 ackDeadline 且 client 未對每則續約，未 ack 的訊息會被重投。Mercari 的 actionable history pipeline 揭露的正是這個 client library 行為：ack deadline 以整批 batch 為粒度運作，同批只要有一則過期或被 nack，已 ack 的訊息會跟著一起重投（3.C63）。

Push、Pull、Streaming Pull 與 flow control

subscription 有兩種交付方向，pull 之下又分 unary pull 與 streaming pull。三者對應不同的下游承壓能力。

Push 把投遞節奏交給 Pub/Sub：endpoint 回 2xx 視為 ack、回非 2xx 或逾時視為 nack 並 backoff 重投。Pull 把節奏交給 consumer：consumer 想拉才拉、拉多少自己定。Streaming pull 是 production 高吞吐場景的主力 — client library 預設用它，因為它能在單一長連線上做精細的 flow control。

flow control 是 pull 的核心優勢：consumer 用 max_outstanding_messages 與 max_outstanding_bytes 設定「同時最多持有多少未 ack 訊息」，超過上限 client 就暫停從連線拉取，等 application ack 釋放額度才繼續。這讓 consumer 能把消費速率對齊到下游能吃的速率，而不是被 broker 灌爆。

Push vs pull 不是實作偏好，是「下游能否接受 push 衝擊」的判讀。Mercari 把外部行銷 webhook（Braze）轉成 Pub/Sub event 後，下游 worker 刻意用 pull subscription 精確控制每秒處理訊息數，因為下游要呼叫的外部 LINE API 有 RPS 限制 — push 會把瞬間流量直接打到受限的外部 API（3.C65）。下游有硬性 RPS 上限時，pull + flow control 是讓消費速率可控的手段。

Ordering Key：有序的代價是吞吐

Ordering key 讓「帶同一個 ordering key 的訊息，在 subscription 端按 publish 順序投遞」。它把全域無序的 Pub/Sub 變成 per-key 有序 — 不同 key 之間仍可並行、亂序，只有同 key 內部保證順序。要生效需要兩端配合：subscription 建立時開 --enable-message-ordering，publish 時帶 --ordering-key。

1# subscription 端開啟 ordering
2gcloud pubsub subscriptions create ord-sub \
3  --topic=ord-topic \
4  --enable-message-ordering
5# describe 可見 enableMessageOrdering: true
6
7# publish 端帶 ordering key（同一 key 的訊息會保序）
8gcloud pubsub topics publish ord-topic --message=m1 --ordering-key=user-123
9gcloud pubsub topics publish ord-topic --message=m2 --ordering-key=user-123

Ordering key 的設計責任在於選對 key 的粒度。粒度太粗（例如所有訊息共用一個 key）會把整條 topic 退化成單線序列、吞吐崩塌；粒度太細（例如每則訊息一個 key）等於沒開 ordering。正確做法是按「需要保序的業務實體」選 key — 同一個 user-123 的事件要保序、不同 user 之間不需要 — 這樣並行度等於活躍 key 數，既保序又不犧牲整體吞吐。

跟 Kafka 對照能看清取捨。Kafka 用 partition + 同 key hash 到同 partition 達成保序，partition 數是固定預先規劃的並行上限；Pub/Sub 沒有顯式 partition，ordering key 的並行度是動態的、由活躍 key 數決定。代價是 Pub/Sub 的有序投遞要求同 key 訊息送到同一個內部處理單元，這個約束讓單一 ordering key 的吞吐有上限（官方標稱單 ordering key 約 1 MB/s）。

Ordering 跟 DLT 在 production 會耦合：有序流裡若一則訊息反覆失敗、Pub/Sub 為維持順序不會跳過它去投後面的訊息，整把 key 的後續訊息全卡住，直到該訊息 ack 或送進 DLT。沒開 ordering 時 poison message 只卡自己；開了 ordering 後它卡住整條 key 序列。這是下一節 DLT 要解的問題在 ordering 場景下被放大的原因。

Dead-Letter Topic：投遞次數上限決定隔離時機

Dead-letter topic 是 poison-message quarantine 在 Pub/Sub 的實作：subscription 對每則訊息計數投遞次數，超過 max-delivery-attempts 就把訊息轉發到另一個 topic（DLT），主 subscription 不再重投它，後續正常訊息得以前進。

 1gcloud pubsub topics create main-topic
 2gcloud pubsub topics create dl-topic
 3
 4gcloud pubsub subscriptions create main-sub \
 5  --topic=main-topic \
 6  --dead-letter-topic=dl-topic \
 7  --max-delivery-attempts=5
 8# deadLetterPolicy:
 9#   deadLetterTopic: projects/<proj>/topics/dl-topic
10#   maxDeliveryAttempts: 5

DLT 是 topic 不是 queue，這是 Pub/Sub 跟 SQS DLQ 的關鍵差異。SQS 的 DLQ 是另一個 queue、消費者直接 receive；Pub/Sub 的 DLT 是 topic，要再掛一個 subscription 才能讀。好處是 DLT 上可以同時掛多個 subscription — 一個給人工檢視、一個給自動 replay、一個給長期歸檔 — fan-out 內建。代價是多一層 subscription 配置，且 DLT 也有自己的 retention（同樣預設 7 天，poison message 要在這之內處理掉）。

max-delivery-attempts 設定的是「容忍多少次暫時性失敗」與「多快放棄」之間的平衡。設太低（例如 1-2 次），下游短暫抖動就把訊息丟進 DLT、誤殺可恢復的訊息；設太高（例如 50 次），一則真正壞掉的訊息會反覆重試半天、占用 consumer 資源、在有序流裡還會長時間卡住整條 key。官方允許範圍 5-100，常見起點是 5。

搭配 retry policy 的 backoff 能讓重投不至於太密集：

1gcloud pubsub subscriptions create retry-sub \
2  --topic=main-topic \
3  --min-retry-delay=10s \
4  --max-retry-delay=600s
5# retryPolicy:
6#   minimumBackoff: 10s
7#   maximumBackoff: 600s

啟用 DLT 需要把 Pub/Sub service account 授權對主 subscription 有 subscriber、對 DLT 有 publisher（emulator 不校驗 IAM，正式環境若漏授權，訊息超過 max attempts 後不會進 DLT、而是繼續留在主 subscription 重投，看起來像 DLT 沒生效）。授權細節依 GCP 官方 IAM 文件。

Mercari 的商品 feed 同步示範了 DLT 的標準用法：pull subscription + 自家 batch requester、成功 ack 整批、失敗 nack 讓 Pub/Sub 重送、重試多次仍失敗送 DLT、後續訊息優先處理；同一個 topic 還兼當突發流量的 load-leveling buffer（3.C64）。

Schema Enforcement：投遞前的契約守門

Schema enforcement 把 event schema compatibility 從「應用層約定」提升到「broker 強制」。topic 綁定一個 Avro 或 Protobuf schema 後，不符 schema 的 publish 在進 topic 前就被拒絕 — 訊息根本不會被儲存、不會投遞、不會進 DLT。

1# 1. 建 schema（Avro，一個必填 string 欄位 id）
2gcloud pubsub schemas create order-schema \
3  --type=avro \
4  --definition='{"type":"record","name":"Order","fields":[{"name":"id","type":"string"}]}'
5
6# 2. topic 綁 schema + 指定 message encoding
7gcloud pubsub topics create sch-topic \
8  --schema=order-schema \
9  --message-encoding=json

綁定後的 publish 行為（emulator 實機驗證 enforce）：

 1# 符合 schema：通過
 2gcloud pubsub topics publish sch-topic --message='{"id":"abc"}'
 3# messageIds: ['4']
 4
 5# 欄位不符 schema：被拒
 6gcloud pubsub topics publish sch-topic --message='{"wrong":123}'
 7# ERROR: INVALID_ARGUMENT: Could not parse message
 8
 9# 非 JSON 垃圾：被拒
10gcloud pubsub topics publish sch-topic --message='not-json'
11# ERROR: INVALID_ARGUMENT: Could not parse message

schema 守門的價值在於把契約破壞擋在 producer 端、而不是 consumer 端。沒有 schema enforcement 時，producer 改了 payload 結構、不相容的訊息照樣進 topic、要到 consumer 解析失敗才爆 — 此時訊息已經在系統裡流動、可能已 fan-out 到多個 subscription、修復成本高。有 schema enforcement 時，不相容的 publish 在源頭就失敗，問題暴露在「誰送了壞訊息」而不是「誰收到壞訊息」。

schema evolution 要在「擋住破壞性改版」與「不阻塞合理演進」之間取捨。新增可選欄位或帶預設值的欄位維持相容、可以平滑演進；新增必填欄位、刪欄位、改型別是破壞性改版，會讓既有 producer 或 consumer 失效。設計上先定相容性等級（backward / forward / full）再演進，刪欄位分兩步（先停用再移除），避免一次破壞性改版打掛下游。

跟 Kafka Schema Registry 對照：Kafka 的 schema 校驗在 client 端（producer / consumer 各自向 Registry 查 schema、序列化時校驗），broker 本身不認識 schema；Pub/Sub 的 schema 綁在 topic、校驗在 broker 端 publish 路徑上。前者校驗點分散、靈活但要求所有 client 守規矩；後者校驗點集中在 broker、強制但耦合到 topic 配置。

五個 Production 故障演練

deep article 的差異化價值在故障演練。以下五個徵兆對應前述三道治理在 production 的典型失效。

演練一：Ordering key 把吞吐限到單線

徵兆：開了 ordering 後整條 topic 的吞吐從數萬 msg/s 掉到數百 msg/s，subscription backlog（num_undelivered_messages）持續攀升、oldest_unacked_message_age 越拉越長，但 consumer CPU 並不滿載 — consumer 在等訊息、不是在忙。

根因：ordering key 粒度太粗。最常見是「所有訊息共用同一個 ordering key」（例如固定字串、或單一租戶 ID），整條 topic 退化成單一有序序列，並行度等於 1。單一 ordering key 的吞吐有上限（官方標稱約 1 MB/s），所有訊息擠進一個 key 就被這個上限封頂。

判讀與修法：

1. 確認 ordering key 的基數（cardinality）。gcloud pubsub topics publish 帶的 --ordering-key 在 production 是業務欄位映射來的 — 檢查映射邏輯是否塌縮成低基數。
2. 把 key 粒度對齊到「真正需要保序的業務實體」：同一筆訂單 / 同一個 user / 同一個 device 內要保序，跨實體不需要。粒度從「全域一個 key」改成「per-user 一個 key」，並行度從 1 拉到活躍 user 數。
3. 評估是否真的需要 ordering。多數 pipeline 靠 consumer 端 idempotency + 版本號就能容忍亂序，不需要 broker 層保序 — 把保序成本從吞吐換成 consumer 設計（見 3.7 event contract 的 idempotency key 段）。

演練二：Ack deadline 太短導致重複投遞

徵兆：consumer 處理邏輯正確、下游也成功，但同一則訊息被處理多次；DELIVERY_ATTEMPT 計數異常偏高、下游出現重複副作用（重複扣款 / 重複發信）。Backlog 不一定高，但「處理量」遠大於「publish 量」。

根因：ackDeadline 比實際處理時間短。預設 10 秒對「呼叫一個慢的外部 API」「處理大 payload」這類任務不夠，訊息在 application 還沒 ack 前就過了 deadline、被 Pub/Sub 重投，於是同一則訊息有多個 consumer 副本在跑。若 client library 的自動 lease extension 沒生效（例如 application 阻塞在同步呼叫、background lease thread 餓死），重投更嚴重。

判讀與修法：

1. 量測 p99 處理時間，把 ackDeadline 設到 p99 之上留 buffer，但不要不加判斷地設到 600 秒上限 — deadline 越長，consumer crash 後訊息重投的延遲越長。
2. 長任務靠 lease extension 而非長 ackDeadline：確認 client library 的自動續約有在跑，application code 不要在處理迴圈裡阻塞到讓 background 續約 thread 餓死。
3. consumer 端做 idempotency：用 message 的 dedup key（3.7）讓重複投遞變成無害 — at-least-once 交付下重複是常態，不靠調 ackDeadline 消除、靠 consumer 設計吸收。

演練三：DLT max delivery attempts 設定誤判

徵兆：兩種反向徵兆。其一，DLT 堆滿了「其實能恢復」的訊息 — 下游一抖動就被丟進 DLT，DLT backlog 暴增、人工 replay 不完。其二，主 subscription 卡著一則壞訊息反覆重投半天都不進 DLT、後面訊息（尤其在 ordering 流裡）全堵住。

根因：第一種是 max-delivery-attempts 設太低（1-2 次），暫時性失敗就被當成 poison。第二種是設太高（數十次）或根本沒設 DLT，真正的 poison message 反覆重試、占資源、卡序列。

判讀與修法：

1. 區分「暫時性失敗」與「結構性失敗」。暫時性（下游超時、限流）需要重試容忍度，結構性（payload 解析不了、業務規則永久拒絕）越早隔離越好。
2. max-delivery-attempts 起點設 5，搭配 retry policy backoff（--min-retry-delay / --max-retry-delay）讓重試之間有間隔、給下游恢復時間，而不是密集重打。
3. 確認 DLT 真的接得到訊息：檢查 Pub/Sub service account 對 DLT 的 publisher 授權（漏授權會讓訊息超過 attempts 後繼續留在主 subscription、看起來像沒進 DLT）。
4. DLT 要掛 subscription 才讀得到 — DLT 是 topic 不是 queue，建完 DLT 還要建 DLT 的 subscription 並設好 retention，否則 poison message 在 DLT 裡放滿 7 天後一樣丟失。

演練四：Push endpoint 500 觸發 retry storm

徵兆：push subscription 的下游 HTTP endpoint 開始大量回 500，Pub/Sub backoff 重投、但 endpoint 仍 500，重投量隨 backlog 累積越滾越大；endpoint 一旦短暫恢復就被積壓的重投流量瞬間打回 500，形成「恢復即再掛」的震盪。

根因：push 的 flow control 由 Pub/Sub 掌握、按 ack 動態調速 — endpoint 回 2xx 視為 ack、非 2xx 視為 nack 並重投。當 endpoint 因下游依賴（DB / 外部 API）掛掉而持續 500，Pub/Sub 的 backoff 重投跟累積的 backlog 疊加，恢復瞬間的流量遠超 endpoint 平時負載。這正是「下游能否接受 push 衝擊」的反面 — push 沒有 consumer 端的 flow control 閥門。

判讀與修法：

1. 先判訊息毒性 vs endpoint 健康。若是 endpoint 整體掛（所有訊息都 500），是容量 / 依賴問題；若是特定訊息 500（多數成功、少數失敗），是 poison message，該走 DLT。
2. endpoint 整體掛的場景，push 不是好選擇 — 改 pull + flow control，讓 consumer 用 max_outstanding_messages 把消費速率對齊到下游能吃的速率，避免恢復瞬間被積壓流量打垮（對照 3.C65 的下游 RPS 限制場景）。
3. 對 push 配 DLT，把反覆 500 的特定訊息隔離出去，避免單一 poison message 混在正常流量裡放大 retry。
4. endpoint 側對「Pub/Sub 重投」做 idempotency，因為 push 也是 at-least-once、500 後的重投會帶來重複。

演練五：Schema enforcement 擋下不相容 publish

徵兆：某次 producer 部署後，該 service 的 publish 開始大量回 INVALID_ARGUMENT: Could not parse message，訊息發不出去；但 consumer 端風平浪靜、沒有任何解析錯誤、backlog 也沒異常。

根因：這通常不是故障、是 schema enforcement 正常運作。producer 改了 payload 結構（加必填欄位 / 改型別 / 漏欄位），新 payload 不符 topic 綁定的 schema，broker 在 publish 路徑上擋下、訊息根本沒進 topic。徵兆出現在 producer 端（publish 失敗）而非 consumer 端（解析失敗），正是 schema 守門把問題前移到源頭的設計意圖。

判讀與修法：

1. 先確認是「該擋」還是「誤擋」。對照 producer 的新 payload 與 topic schema：若是破壞性改版（加必填欄位 / 改型別），enforcement 擋對了 — 該回滾 producer 或先演進 schema。
2. 用 gcloud pubsub schemas validate-message 在部署前 dry-run 校驗 payload 對 schema，把「不相容」暴露在 CI 而不是 production publish。
3. schema 演進走相容路徑：新增欄位帶預設或設可選、刪欄位分兩步、避免一次破壞性改版。先升 schema 再升 producer，順序反了就會出現這個徵兆。
4. 區分 schema enforcement 失敗與 DLT：schema 擋下的訊息不進 topic、不進 DLT（DLT 隔離的是「進了 topic 但消費反覆失敗」的訊息）。兩者是交付管線的不同關卡，徵兆與修法都不同。

容量與選型邊界：標準版 vs Pub/Sub Lite

前述配置適用標準版 Pub/Sub。標準版的計費與容量模型偏向「全域路由內建、按用量計費、不需預先規劃容量」；當吞吐極高且 region 確定時，Pub/Sub Lite 的 partition-based / zonal 模型成本更低。

Pub/Sub Lite 是獨立的 CLI surface（gcloud pubsub lite-topics / gcloud pubsub lite-subscriptions），不是標準版的一個 flag。選 Lite 的代價是要自己 provision partition 數與 throughput capacity（回到接近 Kafka 的容量規劃），換來的是高吞吐穩定流量下顯著更低的成本。判準是吞吐「夠高且夠穩定到值得自己管容量」— 流量彈性大、或不想管 partition 的場景仍該留在標準版。

Spotify 的 autoscaling 案例揭露 backlog 不等於 consumer healthy：下游 export 失敗時 consumer 不 ack 仍持續耗 CPU，autoscaling 把 CPU 越拉越高、反而擴出更多空轉 consumer；解法是 exponential backoff 抑制 CPU 消耗（3.C61）。容量規劃的 autoscale signal 要看「處理成功率」而非「CPU + backlog」，否則擴縮方向會反。

整合與下一步

BigQuery / Cloud Storage subscription：免 consumer 的落地路徑

標準版提供兩種「不需要自寫 consumer」的 subscription，直接把訊息落地到分析 / 儲存層：

• BigQuery subscription（--bigquery-table）：訊息直接寫進 BQ table，免 Dataflow 中介，適合 streaming analytics。可搭配 --use-topic-schema 讓 BQ table schema 對齊 topic schema — schema enforcement 在這裡延伸成「落地結構也受契約約束」。
• Cloud Storage subscription（--cloud-storage-bucket）：訊息批次寫成 GCS object，適合 data lake / 歸檔。

這兩種 subscription 把「event 流 → 分析 / 儲存」的常見管線收進 Pub/Sub 配置，省掉一層自管 consumer。它們仍受同一套 ackDeadline / DLT 骨架管轄。

Cross-link

• 上游 vendor 頁：Google Cloud Pub/Sub overview — 選型層、跟 Kafka / SQS 取捨
• 契約與重播邊界：3.7 Event Contract 與 Replay Boundary — schema / idempotency key / replay window 先於 broker 選型
• 知識卡：Event Schema Compatibility（schema enforcement 守的契約等級）、Poison-Message Quarantine（DLT 的隔離機制）
• 對應 case：3.C64 Mercari Item Feed DLT、3.C65 Mercari LINE flow control、3.C61 Spotify autoscaling、3.C63 Mercari actionable history
• 方法論：Vendor 深度技術文章的寫作方法論

何時 revisit

• ordering key 吞吐撞上單 key 上限、且無法再細分 key：評估改用 Kafka partition 模型，或把保序成本移到 consumer 端 idempotency
• 高吞吐穩定流量 + 成本壓力浮現：評估標準版 → Pub/Sub Lite，接受自管 partition 容量換成本
• schema 需要跨多 vendor 共用契約（同一份 event 同時進 Pub/Sub 與 Kafka）：評估把 schema source of truth 抽到 broker 外的 registry

本文是跨 vendor migration playbook、cross-link 到 Apache Kafka（source）跟 Google Cloud Pub/Sub（target）。跑 6 維 diff dimension audit 後判定為 Type E paradigm shift：兩者投遞模型本質不同（partition-based log vs topic-subscription pub/sub）。

為什麼從 Kafka 遷到 Pub/Sub

這個遷移的 driver 通常是平台策略：

• All-in GCP：組織決定收斂到 GCP 生態，Kafka 是唯一非 GCP 的 stateful 服務，維運孤島成本高
• 運維簡化：自管 Kafka cluster 的 broker、ZooKeeper/KRaft、partition rebalance、retention 管理需要專職團隊；Pub/Sub 是全託管
• GCP 整合：下游是 BigQuery、Dataflow、Cloud Run — Pub/Sub 原生串接，Kafka 要加 connector 層
• 全球路由：Pub/Sub topic 是 global（不綁 region），Kafka 需要 MirrorMaker 做跨 region 同步

遷移的工作量不在資料搬遷（message queue 通常不搬歷史資料），在 模型轉換 — Kafka 的 partition ordering、consumer group、offset commit 跟 Pub/Sub 的 topic-subscription、ack deadline、ordering key 是不同抽象。

6 維 diff dimension audit

五維 High — Type E paradigm shift，是兩套模型的橋接，工程量遠超 drop-in 或翻譯。

模型差異對照

遷移前必須理解兩套模型的對應關係。對應不是一對一 — 有些概念在對方沒有直接等價物。

Ordering 語意是最大差異

Kafka 的 ordering 保證是 partition 內全域有序。同一個 partition 的訊息按寫入順序消費，consumer group 內每個 partition 只有一個 consumer。

Pub/Sub 預設不保證 ordering。要 ordering 需開啟 ordering key — 同一 ordering key 的訊息有序，但不同 ordering key 之間無序。ordering key 的並行度由 key 的 cardinality 決定（類似 Kafka 的 partition key）。

遷移時的判斷：

• 若 Kafka 的 ordering 只依賴 partition key（常見），ordering key 直接對應
• 若依賴 partition 內的全域順序（少見但存在），需要重新設計 — Pub/Sub 沒有 partition 全域順序的概念
• 若完全不需要 ordering（fan-out 場景），Pub/Sub 預設行為更簡單

Component 數量轉換

Kafka 生態的 Schema Registry 在 Pub/Sub 由原生 Schema 功能替代（topic-level schema validation）；Kafka Connect 的 sink connector 由 BigQuery subscription 或 Dataflow job 替代。Dataflow 不是必要 — 簡單的 push/pull consumer 不需要 Dataflow，只有 stream processing（windowed aggregation、join）才需要。

階段一：Producer 遷移（雙寫）

雙寫策略是 paradigm shift 遷移的標準起手。Application 同時把訊息寫入 Kafka 和 Pub/Sub，consumer 仍從 Kafka 消費。

Producer 改造

 1# 示意：雙寫 wrapper（實際生產用各自語言的 client library）
 2def publish_order_event(event):
 3    # 原有 Kafka producer
 4    kafka_producer.send("order-events", key=event.order_id, value=event.to_bytes())
 5
 6    # 新增 Pub/Sub producer
 7    pubsub_publisher.publish(
 8        "projects/my-project/topics/order-events",
 9        data=event.to_bytes(),
10        ordering_key=event.order_id  # 對應 Kafka partition key
11    )

雙寫驗證

雙寫的失敗隔離要嚴格設計。Pub/Sub publish 失敗時，application 應該 log + metric 但不 block request。Kafka 是已驗證的正式路徑，Pub/Sub 在這個階段是 shadow。

階段二：Consumer 遷移（逐 subscription 切換）

Producer 雙寫穩定後，逐一把 consumer 從 Kafka 切到 Pub/Sub subscription。

Consumer 改造重點

Ack 模型差異：Kafka consumer 是 poll + commit offset；Pub/Sub 是 pull（或 push）+ per-message ack。

 1# Kafka consumer pattern
 2for msg in kafka_consumer:
 3    process(msg)
 4    kafka_consumer.commit()
 5
 6# Pub/Sub pull subscriber pattern
 7def callback(message):
 8    try:
 9        process(message.data)
10        message.ack()
11    except Exception:
12        message.nack()  # 會被重新投遞
13
14subscriber.subscribe("projects/my-project/subscriptions/order-processor", callback=callback)

Idempotency 更重要：Pub/Sub 的 at-least-once delivery 加上 ack deadline 機制，redelivery 比 Kafka 更容易觸發（ack deadline 內沒 ack 就重投）。Consumer 的 idempotency 設計要比 Kafka 時更嚴格。

Flow control：Pub/Sub client library 支援 max_outstanding_messages 和 max_outstanding_bytes 做 backpressure 控制，對應 Kafka 的 max.poll.records。

切換順序

依 consumer 的重要度和複雜度排序：

1. 先切 stateless consumer（log pipeline、metrics aggregation）— 低風險
2. 再切有 side effect 但 idempotent 的 consumer（search index sync、notification）
3. 最後切核心 consumer（payment processing、inventory update）— 需要完整 idempotency 驗證

每切一組 consumer：

1. 建立對應的 Pub/Sub subscription
2. 部署新 consumer（讀 Pub/Sub）
3. 驗證處理正確性（比對 Kafka consumer 和 Pub/Sub consumer 的輸出）
4. 停止舊 Kafka consumer
5. 觀察 7 天無異常

階段三：停止雙寫

所有 consumer 切完後：

1. 停止 Kafka producer（移除雙寫邏輯）
2. 觀察 Kafka topic 不再有新訊息
3. 等 Kafka retention 過期
4. 下線 Kafka cluster

Kafka cluster 不要在 consumer 切完後立即下線。保留 retention period + 7 天作為回退保險。

回退路徑

Type E 遷移的回退要在每個階段都設計：

• 階段一回退：移除 Pub/Sub publish 邏輯，Kafka 路徑不受影響
• 階段二回退：重啟 Kafka consumer、停止 Pub/Sub subscriber。Kafka 的 offset 要確認是否仍在 retention 內
• 階段三回退：如果 Kafka 已下線，需要重新建 cluster 並從 Pub/Sub 反向雙寫回 Kafka — 成本高，所以階段三前要確認穩定

回退的關鍵指標：consumer lag（Pub/Sub 的 oldest_unacked_message_age）持續上升、error rate 上升、或 redelivery rate 異常。

遷移後的監控對照

不適合遷移的場景

以下場景 Kafka → Pub/Sub 的 ROI 不成立：

• 需要 exactly-once semantics：Kafka 的 transactional producer + idempotent producer 提供 exactly-once；Pub/Sub 是 at-least-once，application 層做 dedup
• 需要長期 replay：Kafka retention 可設數月甚至永久（tiered storage）；Pub/Sub message retention 最長 31 天（若需超過 31 天的 replay，可用 BigQuery subscription 做長期歸檔，但查詢模式不同於 Kafka 的 offset-based replay）
• 大量 ordering 依賴：如果 Kafka topology 重度依賴 partition ordering 且 key cardinality 低，Pub/Sub ordering key 的並行度會比 Kafka 差
• 使用 Kafka Streams / ksqlDB 做 stateful processing：stream processing 邏輯跟 Kafka 綁定（state store backed by changelog topic），遷到 Pub/Sub 要同時遷移 processing 框架（→ Dataflow / Beam），工程量額外翻倍且 API 完全不同
• 多雲 / 非 GCP 環境：Pub/Sub 是 GCP-only，跨雲場景反而讓 Kafka 更合理

交接路由

• Source vendor overview：Apache Kafka
• Target vendor overview：Google Cloud Pub/Sub
• Pub/Sub 操作細節：Push / Pull / Ack Flow Control、Ordering / DLT / Schema
• Consumer idempotency：3.4 Consumer Design、3.6 Processing Recovery Semantics
• 反向路徑（SQS → Pub/Sub）：AWS SQS → Google Pub/Sub

業務背景

Spotify 的 Event Delivery 系統負責把所有使用者行為事件（播放、搜尋、推薦互動、廣告曝光）從客戶端經由資料管線送到下游消費者。事件是推薦引擎、A/B test、廣告計費跟 analytics 的核心輸入。

遷移到 GCP Pub/Sub 後的系統規模：每個 event type 一個 topic、~15 個 microservice 跑在 ~2500 VM 上、Q1 2019 高峰 8M events/sec、每日 350 TB raw event 流量。遷出 Kafka 的動機跟技術評估見 3.C20 Spotify 遷出 Kafka（反例）。

技術挑戰

At-least-once 語意下的重複

Cloud Pub/Sub（早期版本）提供 at-least-once delivery — 同一筆訊息可能被 deliver 多次。在每日 350 TB 的流量下，「偶爾重複」的頻率足以影響 analytics 數據跟廣告計費的準確性。

Pub/Sub 的重複來源有兩個：ack deadline 到期前 consumer 還沒處理完、訊息被重新 deliver 給其他 consumer；以及 Pub/Sub backend 的內部 redelivery（罕見但非零）。

Pull subscription 的流控

Pull subscription 讓 consumer 主動從 Pub/Sub 拉取訊息（vs push subscription 由 Pub/Sub 推送到 HTTP endpoint）。Pull 的好處是 consumer 可以控制自己的消費速度，避免被推送壓垮。

大規模 pull subscription 的挑戰在於流控的精細度 — 每個 consumer VM 要設定合理的 maxOutstandingMessages 跟 maxOutstandingBytes，太大會讓 consumer 記憶體不足、太小會浪費 Pub/Sub 的吞吐能力。Spotify 的 2500 VM 各自獨立做 pull，需要在 fleet 級別保持流控的一致性。

每個 event type 一個 topic 的治理

Spotify 按 event type 建立 topic（例如 play-event、search-event、ad-impression）。Event type 數量成長後，topic 數量跟著增長。每個 topic 需要獨立的 subscription、monitoring、ack deadline 設定跟 retention policy。

Topic 治理的工程問題是「誰 own 這個 topic、schema 變更怎麼協調、retention 該設多久」。Spotify 自建了 event delivery 平台層（Event Delivery Platform）來管理 topic lifecycle — 包括 topic 建立 / 刪除的 self-service API、schema registry、consumer group 管理。

解法與取捨

自建 deduplication 層

Spotify 在 consumer 端自建去重機制。每筆 event 帶 unique event ID，consumer 在處理前查 dedup store（記憶體 + 外部 cache）確認是否已處理過。已處理的 event 直接 ack、跳過處理邏輯。

Dedup store 的挑戰是大小跟 TTL — 要記住多久以前的 event ID 才夠。TTL 太短會漏掉 late redelivery（Pub/Sub 在 ack deadline 之後才重新 deliver）、TTL 太長 dedup store 太大。Spotify 用滑動視窗（retention 跟 ack deadline 的倍數）設定 TTL。

取捨

自建 dedup 的成本是 Spotify 選 Pub/Sub 的額外付出。這個代價在託管方案的運維節省面前被接受 — 維護一個 dedup cache 的成本遠低於維護跨 5 個 datacenter 的 Kafka broker fleet。

回寫教材的連結

• Pub/Sub vendor 頁：push vs pull subscription、ack deadline、ordering 跟 DLT 的進階主題
• 3.C20 Spotify 遷出 Kafka：遷出 Kafka 的動機跟決策判準
• 3.6 processing recovery semantics：at-least-once 語意下的 dedup 策略
• 3.7 event contract replay boundary：event schema 跟 topic lifecycle 的治理

判讀徵兆

讀者在自己的系統看到以下訊號時，應該回讀本案例：

• 使用 GCP Pub/Sub 且下游消費者偶爾處理到重複事件
• Pull subscription 的 consumer 記憶體使用不穩定、maxOutstandingMessages 設定不合理
• Topic 數量持續增長但缺少統一的 lifecycle 管理
• 從自管 Kafka 遷移到 GCP Pub/Sub 的評估階段

引用源

• Spotify’s Event Delivery — Life in the Cloud

觀察

下游 Cloud Storage export 失敗時、consumer 不 ack 仍持續消耗 CPU 處理同批訊息、造成 autoscaling 把 CPU 越拉越高的反效果；解法是 exponential backoff 抑制 CPU 消耗。

判讀

「Subscription backlog 不等於 consumer healthy」— 訊息未 ack 累積跟 autoscaling 的耦合風險。揭露 autoscale signal 該看「處理成功率」而非「CPU + backlog」。

對應大綱

Pub/Sub 進階主題：Ack deadline / autoscaling signal 設計。

下一步路由

回 Pub/Sub vendor 頁 與 3.5 紅隊章。

引用源

• Autoscaling Pub/Sub Consumers

觀察

Consumer 只在下游 Completionist 回 200 OK 才 ack 回 Pub/Sub、並用「Oldest Unacknowledged Message」metric 判斷 hourly bucket 何時可安全關閉；ack semantics 直接綁定下游 commit。

判讀

ack 是 end-to-end commit 信號、不是 buffer-flush 信號。揭露為什麼後來原生 GCS subscription 有價值（Spotify 早期沒有原生、自建管線）。

對應大綱

Pub/Sub 進階主題：Ack deadline / Cloud Storage subscription（早期無原生、自建對照）。

下一步路由

回 Pub/Sub vendor 頁 與 3.7 event contract / replay boundary。

引用源

• Reliable Export of Cloud Pub/Sub Streams to Cloud Storage

觀察

Merpay 支付流水帳服務用 Pub/Sub 做 async messaging、靠 nack 控制處理順序；踩到「ack deadline 是整批 batch 而非單訊息」、acked 訊息會跟同 batch 其他 expired/nacked 訊息一起 redeliver 的設計細節。

判讀

「ack deadline 是 batch-level」是 Pub/Sub client lib 真實的工程陷阱；idempotency 是處理 duplicate 的必要設計、新出的 exactly-once delivery 才有機會降低重複量。揭露 client lib 的批次語意會「污染」單訊息 ack。

對應大綱

Pub/Sub 進階主題：Ack deadline / Push vs Pull / Ordering key（exactly-once / ordering 章節）。

下一步路由

回 Pub/Sub vendor 頁 與 3.C9 反例：語義誤配。

引用源

• Merpay Actionable History: Displaying Millions of Payments with Lightning Speed

觀察

商品 feed 同步用 pull subscription + 自家 batch requester、成功時 ack 整批、失敗時 nack 讓 Pub/Sub 重送；重試多次仍失敗則送 Dead-letter topic、後續訊息優先處理；topic 同時當突發流量的緩衝。

判讀

直接示範 DLT 在防止 poison message 阻塞 pipeline 的角色、以及把 topic 當 load-leveling queue 的設計。揭露「topic = buffer + dispatch」雙重角色。

對應大綱

Pub/Sub 進階主題：Dead-letter topic / Push vs Pull subscription。

下一步路由

回 Pub/Sub vendor 頁 與 3.C56 PostNL EBE（DLQ 設計對照）。

引用源

• Mercari’s Seamless Item Feed Integration

觀察

Braze webhook 進來後轉成 Pub/Sub event、下游 LINE worker pull subscription「精確控制每秒處理訊息數」、因為外部 LINE API 有 RPS 限制。

判讀

push 會把流量瞬間打到 endpoint、pull 可由 consumer 自行 throttle。揭露 push vs pull 不是「實作偏好」、是「下游能否接受 push 衝擊」的判讀。

對應大綱

Pub/Sub 進階主題：Push vs Pull subscription。

下一步路由

回 Pub/Sub vendor 頁 與 3.C58 Twilio webhook buffer（webhook + buffer 對照）。

引用源

• Flow Control Challenges in Mercari’s LINE Integration

觀察

全球商品同步系統、自建 in-house「PubSub gRPC Pusher」（Pub/Sub 的 gRPC 版 push subscription）解決高吞吐 / 長 job / 彈性 RPS；同時用 message ID 做去重、timestamp 驗證解決重複 + 亂序。

判讀

原生 HTTP push subscription 在「長 job + 高吞吐 + 動態 rate」場景的限制、逼出自建層的工程選擇。揭露 managed broker 的「原生功能」不是所有場景的終點。

對應大綱

Pub/Sub 進階主題：Push vs Pull subscription / Ordering key（亂序的 application-level 處理）。

下一步路由

回 Pub/Sub vendor 頁 與 3.4 consumer 設計。

引用源

• From Local to Global: Building Seamless B2C Product Integration at Mercari

觀察

Pokémon GO frontend 把玩家事件 publish 到 Pub/Sub topic 餵分析 pipeline、再進 BigQuery streaming；高峰 ~1M TPS、Pub/Sub 是 managed service 因此 SRE 維運成本低。

判讀

Pub/Sub 在 publisher 突發流量下作為 elastic buffer、下游 BigQuery streaming 是常見組合。揭露「managed service 的 SRE 成本」是大規模遊戲場景的關鍵選型理由。

對應大綱

Pub/Sub 進階主題：BigQuery subscription（原生 BQ subscription 出現前的 Dataflow pattern）。

下一步路由

回 Pub/Sub vendor 頁 與 3.C68 Wix clickstream（同類組合）。

引用源

• How Pokémon GO Scales to Millions of Requests

觀察

App Engine 收 clickstream → 進 Cloud Pub/Sub queue、再由 Dataflow streaming 處理進 Datastore、dashboard 端到端 latency < 100ms；BigQuery 並行存 raw data 做 recovery。

判讀

「Pub/Sub 當 decouple buffer + Dataflow 當 stream processor + BigQuery 當 raw archive」的 textbook 組合、可作為 BigQuery subscription 出現前的對比 case（為什麼後來原生 BQ subscription 能省掉 Dataflow 中介層）。

對應大綱

Pub/Sub 進階主題：BigQuery subscription / Push vs Pull。

下一步路由

回 Pub/Sub vendor 頁 與 3.C67 Niantic Pokémon GO（同類組合）。

引用源

• Wix Customer Story

觀察

Twitter 把 on-prem 服務的 Avro-formatted 訊息 push 到 Pub/Sub（兩條 stream、較不關鍵但量大的那條 ~80K msg/s 切成 6 個 topic）、下游用 Dataflow + Beam 處理進 Bigtable / BigQuery。

判讀

「把單一 high-volume stream 切成多 topic 做 partition」是 Pub/Sub 沒有 Kafka-style partition 概念下的應對策略。揭露 Pub/Sub 跟 Kafka 的選型差異不是 feature parity、是不同的擴張模型。

對應大綱

Pub/Sub 進階主題：Schema enforcement（Avro 是常見 schema 候選）/ Ordering key（topic 切分 vs ordering key 的取捨）。

下一步路由

回 Pub/Sub vendor 頁 與 Kafka vendor 頁（partition 對照）。

引用源

• Modernizing Twitter’s Ad Engagement Analytics Platform