觀察

FOQS 從區域安裝轉為全域架構，目標是讓災害期間佇列資料仍可被存取，並控制遷移期間的延遲與可用性風險。

判讀

當 queue 成為跨區關鍵路徑，轉換焦點是 discoverability、routing freshness 與 tenant 遷移節奏。

策略

1. 先建立全域路由層，再分批搬遷租戶。
2. 針對 stale routing 做補貨延遲治理。
3. 用零停機遷移策略保留客戶端連續性。

下一步路由

回 3.1 broker basics 與 3.2 durable queue。

引用源

• FOQS disaster-ready migration

觀察

CloudHealth 由自管 Kafka 遷移到 Amazon MSK，過程涵蓋 topic、存取控制、觀測與遷移執行節奏。

判讀

這類轉換的實際風險在 ACL、topic policy、client 相容性與 cutover 節奏，服務名稱本身反而是次要問題。

策略

1. 先建立新叢集治理基線（ACL、觀測、部署）。
2. 分批 topic 遷移並持續監測 lag/錯誤。
3. 把回退與流量切換條件寫成明確門檻。

下一步路由

回 3.1 broker basics 與 6.8 release gate。

引用源

• VMware CloudHealth Kafka to MSK

觀察

LinkedIn 以 TopicGC 清理未使用 topic，降低 Kafka metadata 壓力並改善 produce/consume 效能。

判讀

當 queue 規模擴大，僅靠容量擴充不夠，topic 生命週期與治理自動化會成為可靠性關鍵。

策略

1. 定義 topic 活躍判準與回收條件。
2. 自動化清理流程並保留稽核紀錄。
3. 監控清理前後的性能與穩定性指標。

下一步路由

回 3.4 consumer design 與 6.14 dependency reliability budget。

引用源

• TopicGC at LinkedIn

業務背景

LinkedIn 是 Kafka 的誕生地，內部 Kafka 叢集承載的工作負載涵蓋即時推薦、搜尋索引更新、analytics pipeline、audit log 跟 monitoring。早期所有 workload 共用少數幾個大叢集，隨流量成長，叢集內不同 workload 的資源競爭開始互相影響。

LinkedIn 的 Kafka 規模是全球最大的之一 — 數千個 broker、每秒數百萬筆訊息、PB 級資料保留。在這個規模下，單一叢集的容量限制是 broker 數量跟 ZooKeeper 的 metadata 管理上限，但更早觸及的限制是 workload 之間的干擾。

技術挑戰

Noisy neighbor

即時推薦系統需要低延遲的 consumer（P99 < 50ms），analytics pipeline 是大量 batch consumer（高吞吐但延遲容忍到秒級）。兩者共用同一組 broker 時，batch consumer 的大範圍 sequential read 佔滿 disk I/O，擠壓即時推薦的 random read latency。

一個 analytics job 的重跑（backfill 歷史資料）可以讓推薦系統的 consumer lag 從毫秒跳到秒級。在共享叢集中，這種干擾難以預防 — 只能在事後發現、人工協調。

Broker 故障的影響面

單一叢集中 broker 故障會觸發 partition reassignment，reassignment 的資料搬移佔用 disk I/O 跟網路頻寬。在混合 workload 的叢集中，reassignment 同時影響所有 workload 的效能 — 包括跟故障 broker 無直接關係的 topic。

叢集越大、topic 越多、reassignment 的影響面越廣。

容量規劃的模糊邊界

共享叢集的容量規劃沒有清楚的 owner — analytics 團隊說「我們需要更多 retention」、推薦團隊說「我們需要更低 latency」、audit 團隊說「我們的資料不能丟」。三種需求各自合理，但共享叢集無法同時最佳化。

解法：分層叢集

LinkedIn 按業務風險跟效能需求把 workload 分配到不同叢集：

Tier 1 — 即時關鍵路徑：即時推薦、搜尋索引更新、使用者通知。Broker 配置偏向低延遲（SSD、高 IOPS）、replication factor 3、retention 短（保留足夠的 consumer catchup 時間）。

Tier 2 — 可靠性要求高但延遲容忍：audit log、合規事件、支付事件。配置偏向持久性（replication factor 3、min.insync.replicas 2、acks=all）、retention 長。

Tier 3 — 高吞吐分析：analytics pipeline、ETL、batch processing。配置偏向吞吐（大 batch size、長 linger.ms、HDD）、retention 最長、容忍偶發 consumer lag。

分層的判準

分層的判準是「這個 workload 故障時，業務影響有多大、多快」：

• 即時影響使用者體驗 → Tier 1
• 影響合規或財務但可容忍分鐘級延遲 → Tier 2
• 影響分析準確性但可容忍小時級延遲 → Tier 3

取捨

分層的成本是資源利用率下降 — 每層都需要保留一定的 headroom 應對高峰，加總起來比共享叢集多。LinkedIn 的判斷是隔離性的價值大於利用率的損失 — 推薦系統一次 P99 退化的業務損失遠大於多幾台 broker 的成本。

回寫教材的連結

• 3.1 broker basics：broker 配置怎麼影響延遲 vs 吞吐 vs 持久性的取捨。
• 6.14 dependency reliability budget：不同 tier 的 Kafka 叢集各自有不同的 reliability budget。
• 3.4 consumer design：batch consumer 跟 real-time consumer 的資源消耗差異。

判讀徵兆

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

• 即時消費者的 consumer lag 因為同叢集的 batch job 而上升
• Broker 故障後的 partition reassignment 影響到跟故障無關的 topic
• 容量規劃會議中不同團隊的需求互相矛盾、無法在同一組配置中滿足
• Kafka 叢集的 topic 數量超過 500 個、workload 類型超過三種

引用源

• Running Kafka at Scale at LinkedIn

觀察

Slack 在 job queue 擴展中使用 Kafka 與 Redis 分工，處理吞吐與即時性需求。

判讀

當背景工作同時要高吞吐與快速反應，單一通道模型通常會變成瓶頸。

策略

1. 把不同工作類型切到不同傳遞路徑。
2. 分別治理持久性與即時性目標。
3. 以 lag、重試與失敗重播驗證穩定性。

下一步路由

回 3.2 durable queue 與 3.3 outbox pattern。

引用源

• Scaling Slack’s Job Queue

業務背景

Uber 的事件流涵蓋行程追蹤、司機定位、計費事件、推播通知、即時定價、ETA 計算跟 analytics。早期各團隊各自架設 Kafka 叢集，隨著 Kafka 在 Uber 內部的採用率上升，叢集數量跟 topic 數量快速增長，但沒有統一的治理。

Uber 的 Kafka 規模峰值達到每秒數百萬筆訊息、數十個叢集、數千個 topic。在這個規模下，管理壓力從「單一叢集的 broker 夠不夠」轉到「誰在用、用多少、怎麼收費、故障時誰負責」。

技術挑戰

團隊自管的碎片化

各團隊各自架設 Kafka 時，每個叢集的版本、配置、監控、備份策略都不同。運維知識散落在各團隊，沒有共享的 runbook 或值班流程。某個團隊的 Kafka 出問題時，其他團隊幫不上忙；知識在人員流動時遺失。

碎片化的另一個後果是資源浪費。每個團隊各自預留的容量加總起來遠大於集中管理所需。低流量團隊的叢集常年使用率低於 10%，但因為自管模式下沒有共享容量的機制，資源無法調配。

Topic 爆炸與無主 topic

沒有 topic 建立的治理流程時，任何人都可以建 topic。Topic 的命名不一致、retention 設定不一致、owner 不明。離職的工程師建立的 topic 仍在接收資料、佔用 broker 資源，但沒人知道這些 topic 服務什麼業務。

LinkedIn 後來也遇到同樣的問題並開發了 TopicGC 做 topic 生命週期管理。Uber 的解法路線類似 — 把 topic 建立變成需要 owner、retention policy 跟業務標籤的審核流程。

故障排查的責任不清

叢集內的故障（broker OOM、partition leader 不均衡、consumer lag spike）需要 Kafka 專業知識排查。團隊自管模式下，每個團隊都需要一定程度的 Kafka 運維能力，但多數團隊的核心能力是業務邏輯而非 MQ 運維。

故障排查的慣性是「先問 Kafka 團隊有沒有人可以幫忙」— 但沒有正式的 Kafka 團隊，所以問的是「上次修過 Kafka 的那個人」。

解法：平台化

Uber 的解法是把 Kafka 從分散自管收斂到集中平台 — 一個專責的 Kafka platform team 統一管理所有叢集、提供標準化的使用介面。

多租戶治理

平台化的核心是多租戶模型 — 每個業務團隊是一個 tenant，tenant 有 quota（ingestion rate、partition 數量上限、retention 上限）跟 cost attribution。

Quota 的目的是防止單一 tenant 的爆量拖累整個平台。Cost attribution 的目的是讓 tenant 看到自己的用量跟成本，驅動合理使用。

標準化 topic 管理

Topic 的建立走 self-service portal — 團隊填寫 owner、業務用途、預估流量、retention 需求，portal 自動配置 topic 並建立監控。沒有 owner 的 topic 不允許建立；owner 離職時 topic 需要交接或標記為候選淘汰。

統一監控與值班

Platform team 統一監控所有叢集的 broker 健康（replication lag、under-replicated partitions、disk usage、CPU），提供共用的 dashboard 跟 alert。值班由 platform team 負責 broker 層面的問題，業務層面的問題（consumer 設計錯誤、message 格式不對）由各 tenant team 自行處理。

取捨

平台化的最大風險是共享平台成為單點 — broker 故障影響所有 tenant。Uber 用跟 LinkedIn 類似的分層叢集策略（critical vs best-effort）降低共享風險，但這也讓平台的運維複雜度上升。

回寫教材的連結

• 3.1 broker basics：broker 容量規劃跟 topic 管理的基礎。
• 6.14 dependency reliability budget：共享 Kafka 平台作為 dependency，tenant team 的 reliability budget 怎麼計算。
• 3.4 consumer design：平台化後 consumer 設計的規範跟限制。
• 4.15 cost attribution：平台成本歸因到 tenant 的做法。

判讀徵兆

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

• 組織內有 3 個以上團隊各自架設 Kafka、版本跟配置不統一
• Topic 數量持續增長但沒人能說清楚哪些 topic 還在用
• 故障排查依賴特定個人而非共用的 runbook
• 叢集資源利用率低但各團隊仍要求擴容
• 管理層問「Kafka 總共花多少錢、誰在用」但沒人能回答

引用源

• Building Uber’s Kafka Infrastructure

觀察

LinkedIn 在 Kafka 維運中導入自動化治理，降低人工介入與恢復時間波動。

判讀

當叢集規模超過人力可及範圍，自動修復與治理工具會成為必要能力。

策略

1. 明確定義可自動修復的故障類型。
2. 將自動修復與人工升級條件分離。
3. 把修復過程納入可觀測證據鏈。

下一步路由

回 3.2 與 8.16。

引用源

• Automating Kafka Self-Healing at LinkedIn

觀察

Cloudflare Queues 以邊緣網路為背景，提供事件傳遞與 consumer 處理能力。

判讀

全球部署下，queue 模型要同時考慮延遲、重試語義與跨區運維一致性。

策略

1. 明確設定 delivery semantics 與重試策略。
2. 把 consumer 行為與死信處理流程標準化。
3. 將 queue lag 與失敗率接入平台觀測。

下一步路由

回 3.4 與 4.11。

引用源

• Introducing Cloudflare Queues

事故長相

切換 broker 或 consumer group 後，表面上訊息仍然被送達，但業務資料開始出現重複扣款、重複寄信、狀態漏更新這類問題。這種事故很難只靠 queue depth 判斷，因為錯誤發生在「處理語義」而不是「是否有訊息」。

為什麼會擴大

舊系統若依賴特定 offset 行為、重試節奏或 consumer idempotency，新系統即使名稱上提供相近 delivery semantics，也可能在失敗重播時產生不同結果。語義誤配會沿著下游資料寫入擴散。

回退判讀

回退前要先確認哪一段資料已經被新語義處理過。若直接切回舊 broker，可能讓同一批事件再次被處理。更穩定的做法是先凍結新 consumer，保留 offset 對照與 replay 範圍，再決定補償或重播。

Queue 專屬告警條件

• 下游 reconciliation 同時出現重複與遺漏
• DLQ 激增且重播後仍回到相同錯誤
• consumer lag 下降但業務結果沒有收斂

下一步路由

回 3.4 與 6.10。

小型服務常見判讀

小型服務優先用 managed queue 往往最穩，因為運維成本最低。這時候最容易忽略的是語義邊界：重試次數、死信規則、重播責任如果沒先定義，規模一上來就會出現資料重複與漏處理。

中型服務常見判讀

中型服務常見問題是 lag 與 DLQ 長期累積。根因通常是 consumer idempotency、重播流程、下游承載能力沒有一起設計，broker 效能本身很少是單點問題。

大型服務常見判讀

大型服務需要處理跨租戶與跨區壓力。此時若還用單叢集思維，任何一類流量尖峰都會拖垮整體。重點會從「怎麼送訊息」轉成「怎麼隔離失敗」。

這個情境的專屬告警條件

• consumer lag 連續超出 SLO 窗口
• DLQ 速率上升且無法在固定時間內回收
• 重播後仍出現相同失敗模式

出現上述條件應先凍結切換，回到前一語義設定，再逐步修正 consumer 契約與重播流程。

觀察

Pinterest 從 Kafka broker 卸 ~200 TB/day 熱資料到 S3、2024 年 5 月起 20+ production topic 上線、跟 KIP-405 native tiered storage 不同、採 broker-decoupled 設計。

判讀

Broker-decoupled 設計讓 consumer 直接從 S3 拉、broker 不再是熱路徑。揭露「broker resource 跟 cross-AZ network cost」其實該分離治理、而非綁在 broker 容量擴張上。

對應大綱

Kafka 進階主題：tiered storage / 跨層儲存成本。

下一步路由

回 Kafka vendor 頁 與 3.1 broker basics。

引用源

• Pinterest Tiered Storage for Apache Kafka — a Broker-Decoupled Approach

觀察

Pinterest 三個 AWS region（us-east-1 / us-east-2 / eu-west-1）跑 MirrorMaker v1、原版設計把 record 解壓+重壓、memory 用量 2-10x 於網路 bytes、CPU spike 與 OOM 頻繁。

判讀

Shallow Mirror 在 RecordBatch 層淺迭代 + ByteBuffer pointer 共享、避開 deserialize/re-compress。揭露「跨區同步不是純 I/O 問題、是 CPU + memory + 網路三維壓力」。

對應大綱

Kafka 進階主題：cross-region MirrorMaker / MirrorMaker 2 配置。

下一步路由

回 Kafka vendor 頁 與 3.C1 Meta FOQS。

引用源

• Pinterest Shallow Mirror

業務背景

Shopify 的核心資料儲存是 100+ 個 MySQL shard，每個 shard 承載不同商家的交易資料。下游系統（搜尋索引、analytics、資料倉儲）需要近即時地取得資料變更。原本用 query-based 方案（內部系統 Longboat）輪詢資料庫，但隨 shard 數量跟資料量成長，輪詢的延遲跟資料庫負載壓力持續惡化。

遷移到 log-based CDC（Debezium over Kafka Connect）後，pipeline 的穩態規模是 ~150 個 Debezium connector 跑在 12 個 Kubernetes pod、Black Friday peak 100K records/sec、P99 latency < 10s。

技術挑戰

Snapshot 鎖定 read replica

Debezium 在初始同步（snapshot）時需要取得一致性快照。MySQL connector 的預設行為是對 read replica 取 global read lock，鎖住的時間跟表大小成正比。Shopify 的大表 snapshot 可能鎖住 read replica 數小時，影響線上查詢。

Shopify 工程師直接向 Debezium 上游貢獻了「lock-free snapshot」機制 — 用 MySQL 的 GTID（Global Transaction ID）確保一致性，取代 global read lock。這個改動後來合併進 Debezium 主線，所有使用者都受益。

Oversized record

MySQL 的 blob / text 欄位可能產生超過 1 MB 的 CDC record。Kafka 的 message size limit（預設 1 MB）會讓這些 record 被 producer 拒絕。調大 max.message.bytes 是一個選項，但會影響 broker 的記憶體跟 replication 效率。

Shopify 的解法是把 oversized payload 寫到 GCS（Google Cloud Storage），CDC record 只帶 GCS pointer。Consumer 端在需要完整資料時再從 GCS 取。這個 pattern 把 Kafka 維持在「傳遞事件 metadata」的定位，大型 payload 走 object storage。

Connector 故障隔離

150 個 connector 跑在 12 個 pod 上，一個 connector 的 failure（例如某個 shard 的 MySQL 做了 schema change、binlog 格式不相容）可能影響同 pod 上的其他 connector。Shopify 用 Kafka Connect 的 distributed mode + task rebalance 做故障隔離，但 rebalance 本身在 connector 數量多時有延遲。

解法與取捨

回寫教材的連結

• 3.3 outbox pattern：CDC 是 outbox pattern 的 log-based 替代方案。Shopify 的 case 揭露 CDC 的工程成本集中在 snapshot 跟 schema evolution，outbox 的成本集中在應用層 dual-write。
• Kafka vendor 頁：Kafka Connect / CDC 的進階主題。
• 3.1 broker basics：message size limit 跟 broker 資源的關係。

判讀徵兆

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

• CDC snapshot 過程持續數小時、鎖住 read replica 影響線上查詢
• CDC record size 頻繁超過 Kafka 的 message size limit
• Kafka Connect connector 數量超過 50 個、rebalance 時間開始明顯增長
• 從 query-based 同步（輪詢）切換到 log-based CDC 的評估階段

引用源

• Capturing Every Change From Shopify’s Sharded Monolith

觀察

Yelp data pipeline 一天數十億訊息、跨數百個 service、數千 schema、用自建 Schematizer 強制所有 message 走 Avro schema、訊息只帶 schema ID。

判讀

Schematizer 不只是 schema store、還做 schema evolution compatibility 與 topic 自動分配（不相容 schema 強制新 topic）。揭露 producer / consumer schema 治理要拉到平台層、靠工具強制、不靠人約定。

對應大綱

Kafka 進階主題：Schema Registry / Schema evolution。

下一步路由

回 Kafka vendor 頁 與 3.7 event contract / replay boundary。

引用源

• Yelp Schematizer: More than just a schema store

觀察

Airbnb logging pipeline 跨多個 topic、event size 從幾百 bytes 到幾百 KB、QPS 跨數個量級差異、Spark 一個 partition 對一個 task 造成 data skew、catch-up 一個 4 小時 lag 要再花 4 小時。

判讀

自建 balanced Spark Kafka reader、把 parallelism 從 partition 數解耦、按 event volume × size 重新分派 work。揭露 partition 數不該等同 consumer parallelism、要看 event 形狀。

對應大綱

Kafka 進階主題：Consumer 設計 / consumer lag / rebalance / partition + consumer group。

下一步路由

回 Kafka vendor 頁 與 3.4 consumer 設計。

引用源

• Scaling Spark Streaming for Logging Event Ingestion

觀察

Robinhood 每天處理 billions of events / TB 資料、用於 risk signal、order quality、market data、fraud detection；team 多為 Python、不想用 JVM 生態。

判讀

把 Kafka Streams 的 stateful streaming 模式（topology、tables、windowing）移植到 Python library 形式、不需要 Yarn / Mesos resource manager。揭露 stream processing framework 選型常被語言生態主導、不是技術 feature。

對應大綱

Kafka 進階主題：跨語言 client / Streams framework / stream processing on Kafka。

下一步路由

回 Kafka vendor 頁 與 3.4 consumer 設計。

引用源

• Faust: Stream Processing for Python

觀察

Walmart 每天 trillions of message、25K+ Kafka consumer 跑在 WCNP Kubernetes 多雲環境；最大痛點是 pod scaling / deploy / heartbeat fail 觸發 consumer rebalance、lag spike。

判讀

自建 Messaging Proxy Service（MPS、Kafka Connect sink connector）、把 consumer 從 partition-bound 解耦成 stateless REST service、可獨立 auto-scale、不用增 partition；內建 DLQ 處理 poison pill。揭露「consumer 該跟 partition 數綁定」這個假設在 K8s 規模化下不再成立。

對應大綱

Kafka 進階主題：rebalance storm / consumer lag / multi-tenant 配額。

下一步路由

回 Kafka vendor 頁 與 3.4 consumer 設計。

引用源

• Reliably Processing Trillions of Kafka Messages Per Day

觀察

Wix 2000+ microservice、每天 66 billion Kafka 訊息、用自建 Greyhound（JVM library + polyglot sidecar）抽象 Kafka；troubleshooting 痛點是「卡住的 consumer 看不到原因、只能寫 DB 修復腳本」。

判讀

TLLSR 框架（Trace / Lookup / Longest-running / Skip-replay / Redistribute）解 single-partition lag、單筆 poison pill、handler 卡住等情境；consumer lag alert > 30 分鐘觸發。揭露原生 lag metric 無法定位「卡在哪」、需要 message-level trace + 操作介面。

對應大綱

Kafka 進階主題：consumer lag / observability / multi-tenant / poison message。

下一步路由

回 Kafka vendor 頁 與 3.5 紅隊章。

引用源

• Troubleshooting Kafka for 2000 Microservices at Wix

觀察

Wix cluster metadata 從 2019 年 5K topic / 45K partition 漲到 20K topic / 200K partition、每日 record 從 450M 漲到 2.5B、controller startup 與 broker stability 受 metadata 量壓垮。

判讀

不用 MirrorMaker、自建 Replicator service + Migration Orchestrator、用 Kafka topic 當控制平面協調 consumer 切換 + offset mapping；按 SLA 切多 cluster。揭露「topic / partition 數量」是 broker 級別的物理上限、不能無限擴張。

對應大綱

Kafka 進階主題：cross-region MirrorMaker / topic 生命週期 / 分層叢集策略。

下一步路由

回 Kafka vendor 頁 與 3.C3 LinkedIn TopicGC。

引用源

• Migrating to a Multi-Cluster Managed Kafka with 0 Downtime

業務背景

Spotify 的事件傳遞系統（Event Delivery）負責把使用者行為事件（播放、搜尋、推薦互動）從客戶端送到資料管線。系統跨 5 個 datacenter 運行 Kafka 0.7，production peak 700K events/sec、pressure test 達到 2M events/sec。事件資料是推薦系統、analytics 跟廣告計費的輸入，遺失事件直接影響商業決策的準確性。

2016 年，Spotify 決定把 Event Delivery 從 Kafka 遷移到 GCP Pub/Sub，而非升級到當時已發布的 Kafka 0.8+。

技術挑戰

MirrorMaker 的 best-effort 語意

Kafka 0.7 的跨 datacenter replication 工具 MirrorMaker 在 best-effort mode 下會丟失資料但向 producer 回報成功。對 Spotify 的場景，producer 端認為事件已送達，但跨 datacenter 的 mirror 實際上丟了一部分。丟失比例在正常情況下很低，但在 broker restart 或網路抖動時可以升高到影響 analytics 準確性的程度。

這個問題的根源是 Kafka 0.7 的 producer 沒有 idempotent 保證，MirrorMaker 的 consumer offset commit 跟 producer ack 之間有 gap。

Broker restart 後 producer 無法自動恢復

Kafka 0.7 的 producer 在 broker restart 後可能進入無法自動恢復的狀態 — 需要人工重啟 producer process。在 5 個 datacenter、數百個 producer instance 的規模下，每次 broker 維護操作都需要人工介入恢復 producer，運維成本跟 broker 數量成正比。

為什麼不升級到 Kafka 0.8+

Kafka 0.8 引入了 replication、新的 consumer API 跟更可靠的 producer。但 Spotify 評估後認為升級的成本接近重新部署：

• Kafka 0.7 到 0.8 的 wire protocol 不相容，需要全量遷移而非滾動升級
• 所有 producer / consumer 的 client library 都要更換
• Spotify 同時在向 GCP 遷移基礎設施，Kafka 的自管運維模式跟 GCP 的託管方向不一致

相比之下，GCP Pub/Sub 提供了託管的 exactly-once 語意、跨 region replication、零運維。遷移成本跟升級 Kafka 版本的成本相當，但遷移後的長期運維成本低得多。

解法與取捨

Spotify 的判斷是：在同時進行 GCP 遷移的背景下，維護自管 Kafka 的投資回報比不上切換到託管方案。這個判斷跟 Kafka 本身的能力無關 — Kafka 0.8+ 的可靠性已經解決了 0.7 的問題。決策的關鍵變數是「組織正在往哪走」，不只是「技術上哪個更好」。

回寫教材的連結

• Kafka vendor 頁：cross-region replication 跟 MirrorMaker 的進階主題。Spotify 的案例是「早期版本限制」的歷史教訓，Kafka 3.x 的 KRaft + idempotent producer 已解決這些問題。
• Pub/Sub vendor 頁：託管 MQ 的定位跟適用場景。
• 3.6 processing recovery semantics：exactly-once 語意的工程實踐。Spotify 案例揭露 exactly-once 在早期 Kafka 版本不成立。
• 3.1 broker basics：broker 版本跟可靠性保證的關係。

判讀徵兆

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

• 使用舊版 Kafka（< 2.0）且跨 region replication 的資料完整性無法驗證
• Broker restart 後需要人工重啟 producer、運維成本跟 broker 數量成正比
• 組織正在做基礎設施遷移（on-prem → cloud），考慮是否同步切換 MQ
• 評估「升級現有系統 vs 遷移到新系統」的決策框架

引用源

• Spotify’s Event Delivery — The Road to the Cloud (Part II)

觀察

Global Investment Research 把 ~12 microservice / 30 instance 從 on-prem Kafka 遷到 MSK；用 MM2 同步 topic / ACL / consumer group / offset、選擇 atomic cutover、整體耗時 ~7 小時。

判讀

把 MM2 預設的 prefixed topic 改成 identical name；遇到 flush timeout（5s → 30s）、request size、NLB idle timeout 350s vs client 540s 衝突。揭露 managed 服務遷移的細節風險集中在「LB / timeout / topic naming」這些 client 端配置、不在 broker 本身。

對應大綱

Kafka 進階主題：cross-region MirrorMaker / managed broker 遷移 / ACL 設計。

下一步路由

回 Kafka vendor 頁 與 3.C2 VMware → MSK。

引用源

• How Goldman Sachs Migrated from On-Premises Apache Kafka to Amazon MSK

觀察

Trivago 跨 3 個 region 跑 50+ Kafka sink service、每個 always-on 用 1 CPU + 1 GB；CPU/mem-based autoscaling 無效（sink 多為 I/O bottleneck、CPU 平坦）。

判讀

KEDA 以 consumer lag 為 scaling signal、minReplicaCount=0 達到 scale-to-zero、daily replica-hour 從 50 降到 1-2。揭露「resource usage 不等於工作量」、event-driven 場景該看 backlog signal。

對應大綱

Kafka 進階主題：consumer lag / autoscaling / multi-tenant 配額。

下一步路由

回 Kafka vendor 頁 與 3.4 consumer 設計。

引用源

• From Always-On to On-Demand: Scaling Kafka Sinks with KEDA

業務背景

Bloomberg 有 5000+ 工程師，內部系統涵蓋金融資料處理、交易系統、新聞分發與分析平台。RabbitMQ 的使用從最初幾個團隊的 microservice 解耦開始，逐步擴展到上百個團隊。到 2019 年，Bloomberg 的 RabbitMQ 基礎設施每週處理超過 2 億條訊息，尖峰每秒數萬條。

這個規模下，原本由平台團隊手動配置的 queue / exchange / binding 模式無法持續 — 上百個團隊各自有不同的 queue 需求，平台團隊成為所有變更的人工瓶頸。

技術挑戰

多租戶隔離

多個團隊共用同一個 RabbitMQ cluster 時，一個團隊的 queue 爆量或 consumer 故障可能影響其他團隊的訊息處理。RabbitMQ 的 Erlang scheduler 是共用的 — 一個 queue 的 message accumulation 會消耗 broker 的記憶體跟 CPU，影響同 cluster 上所有 queue 的效能。

隔離需要在 broker 層實作，client 端的 best practice（限制 message size、設定 TTL）只能降低風險但無法保證隔離。

自助配置的安全邊界

讓上百個團隊自助建立 queue / exchange / binding 需要明確的安全邊界 — 團隊 A 能在自己的 namespace 建立資源，但不能存取團隊 B 的 queue。RabbitMQ 的 vhost 機制提供了這個隔離單位，但 vhost 的建立跟權限配置本身需要自動化。

容量規劃與配額

共享 cluster 的容量被所有租戶分攤。沒有配額機制時，一個團隊的 queue 可以無限增長直到 broker 記憶體告警、觸發 flow control、影響全部租戶。配額需要在 queue 層面設定上限（max-length、max-length-bytes），同時提供超出配額時的降級策略而非直接拒絕。

解法：vhost 分層 + 自助平台

Vhost 作為租戶邊界

Bloomberg 把 vhost 作為多租戶隔離的基本單位。每個團隊（或每個應用）分配一個 vhost，vhost 內的 queue / exchange / binding 只對該團隊可見。跨 vhost 的訊息傳遞透過 shovel 或 federation plugin，需要顯式配置，預設不互通。

Vhost 的隔離粒度是「資源可見性 + 權限」而非「硬體資源」。同 cluster 上的 vhost 仍然共用 Erlang runtime 跟記憶體。完全的硬體隔離需要獨立 cluster — Bloomberg 對高敏感度的工作負載（交易相關）使用專用 cluster，一般業務共用大 cluster + vhost 隔離。

自助 vhost 註冊

Bloomberg 建立了內部自助平台，團隊透過 API 或內部 portal 申請 vhost。申請時需要提供：應用名稱、預期的 message rate、保留期限、是否需要 HA（mirrored / quorum queue）。平台自動建立 vhost、設定權限、分配連線端點。

自助流程的價值是去除平台團隊的人工瓶頸。新團隊從申請到拿到可用的 RabbitMQ 端點，時間從「提 ticket 等平台團隊排程」縮短到「填表 → 自動配置 → 立即可用」。

配額與監控

每個 vhost 有預設配額（max-length、max-connections）。超出配額時 broker 行為可配 — drop-head（丟最舊的訊息）或 reject-publish（拒絕新訊息）。配額不是懲罰機制，是保護共享 cluster 的防線。

監控用 RabbitMQ 的 management plugin + Prometheus exporter，按 vhost 維度匯出 queue depth、message rate、connection count。每個 vhost 的 dashboard 對應到 owner 團隊，讓團隊自行判讀自己的使用狀況。

取捨

Vhost 隔離 vs 硬體隔離：vhost 隔離成本低（不需要額外 cluster），但隔離程度有限 — Erlang scheduler 跟記憶體仍然共用。Bloomberg 的做法是多數團隊用 vhost 隔離、高敏感度工作負載用專用 cluster，兩者共存。

自助配置 vs 中央管控：自助配置加速團隊迭代，但也增加了 configuration drift 的風險。Bloomberg 透過配額跟自動化審計（定期掃描 vhost 的 queue 狀態、alert 異常 pattern）平衡自助跟管控。

回寫教材的連結

• 3.1 broker basics：broker 的多租戶治理責任
• 3.C6 Uber Kafka 平台：Kafka 生態的多租戶治理比較 — Kafka 用 topic-level ACL + quota，RabbitMQ 用 vhost
• 4.18 operating model：平台團隊跟服務團隊的 ownership 邊界

判讀徵兆

以下訊號出現時，應該回讀本案例：

• RabbitMQ 的使用團隊數從個位數增長到雙位數、平台團隊成為配置瓶頸
• 單一 cluster 上的 queue 數量超過數百個、owner 不明
• 某個團隊的 queue 爆量影響了其他團隊的 consumer 效能
• 新團隊要用 RabbitMQ 但平台團隊的 ticket 要排隊數天
• 沒有 per-team 的 message rate 或 queue depth 監控

引用源

• Growing a Farm of Rabbits at Bloomberg

觀察

上傳音訊後用 RabbitMQ 觸發 transcode + 波形圖 + follower 通知。當 Skrillex 等大號上傳時、要避免同步寫 Cassandra 千萬次。每秒 20-30,000 條 persistent message。

判讀

不同處理類型分開隊列、各自獨立 scale。揭露 fan-out 不是「broadcast 同一份工作」、而是「同事件觸發多種獨立 pipeline」、每種 pipeline 的 throughput / latency 要求不同。

對應大綱

RabbitMQ 進階主題：Prefetch + consumer 併發 / classic queue vs Streams（log fan-out 場景）。

下一步路由

回 RabbitMQ vendor 頁 與 3.4 consumer 設計。

引用源

• Scaling with RabbitMQ at SoundCloud (VMware Tanzu)
• AMQP at SoundCloud (InfoQ)

業務背景

Indeed 是全球最大的求職搜尋引擎之一，每天處理 35M+ 筆職缺資料的索引、更新與推送。職缺資料從雇主端進入系統後，需要經過解析、標準化、索引、推送到搜尋引擎等多個處理步驟，每個步驟由 RabbitMQ 串接的 consumer 處理。

這個規模下，任何一個處理步驟的暫時失敗（downstream service timeout、資料格式異常、外部 API rate limit）都會產生需要 retry 的訊息。每天有數十萬筆訊息需要至少一次 retry。

技術挑戰：Head-of-line blocking

Indeed 原本的 retry 策略是 consumer 處理失敗時把訊息 requeue（basic.nack with requeue=true）。RabbitMQ 的 requeue 行為是把訊息放回 queue 的 head — 下一次 consumer 拿到的還是這條失敗的訊息。

當一條訊息因為 downstream timeout 反覆失敗時，它會持續佔住 queue head，阻塞後面所有等待處理的訊息。單一 consumer 的時間被一條失敗訊息反覆消耗，其他正常的訊息延遲累積。在 35M+ 筆/天的吞吐量下，一條 head-of-line blocking 訊息就能讓整個 pipeline 的 processing lag 從秒級升到分鐘級。

這個問題的根源是 retry 策略跟 queue 拓樸耦合在一起 — requeue 把 retry 決策留在同一個 queue 裡，讓失敗訊息跟正常訊息搶同一條通道。

解法：三層 escalation

Indeed 設計了一個三層 escalation 模型，把失敗訊息依嚴重程度逐層隔離：

第一層：Immediate retry（同 queue）

Consumer 處理失敗時，先在 client 端做短暫 backoff（數百毫秒到數秒），然後 ack 原訊息、重新 publish 到同一個 queue 的 tail（而非 requeue 到 head）。

這層處理的是暫態錯誤 — downstream 偶發的 500、短暫的 network hiccup。多數訊息在第一層就能恢復。重新 publish 到 tail 確保失敗訊息排在正常訊息後面，不阻塞其他訊息。

第二層：Delay queue

第一層 retry N 次仍然失敗的訊息，透過 RabbitMQ 的 Dead Letter Exchange（DLX）路由到 delay queue。Delay queue 用 x-message-ttl 設定延遲時間（例如 30 秒、1 分鐘、5 分鐘），TTL 到期後訊息透過另一個 DLX 路由回原始 queue 的 tail。

Indeed 用多個不同 TTL 的 delay queue 實作 exponential backoff — 第一次進 delay 等 30 秒、第二次等 1 分鐘、第三次等 5 分鐘。這個做法利用 RabbitMQ 原生的 DLX + TTL 機制，不需要額外的 scheduler 或 cron job。

這層處理的是持續性錯誤 — downstream 在做 deployment、外部 API 在做 maintenance。延遲重試讓 downstream 有時間恢復，同時失敗訊息完全離開主 queue、不影響正常處理。

第三層：Dead Letter Queue

Delay queue retry M 次後仍然失敗的訊息進入 DLQ。DLQ 中的訊息不再自動重試，需要人工審視或批次 replay。

DLQ 的價值是把「目前無法處理」的訊息安全保存，不讓它們無限消耗 retry 資源。Indeed 的維運團隊定期檢查 DLQ 中的訊息 — 按 error type 分群、判斷是 bug（需要修 code 再 replay）還是資料問題（需要修正資料再 replay）。

取捨

犧牲的是 delivery order。訊息從 delay queue 回到主 queue tail 時，已經不在原始的位置。對 Indeed 的職缺處理來說，order 不影響正確性 — 職缺更新是 idempotent 的，最終狀態正確即可。對 order-sensitive 的場景，這個模型需要額外的 ordering 機制。

增加的是拓樸複雜度。三層 escalation 涉及主 queue + 多個 delay queue + DLQ + 多個 DLX 的 binding。RabbitMQ 的 exchange / queue / binding 組合需要明確規劃跟文件化，否則維運時搞不清楚訊息的路由路徑。

回寫教材的連結

• 3.2 durable queue：DLX + TTL 是 RabbitMQ 原生的 durable 機制
• 3.6 processing recovery semantics：retry 策略跟 consumer 的 ack/nack 行為
• RabbitMQ DLQ retry escalation：DLX 配置的實作細節
• 3.C6 Uber Kafka 平台：Kafka 生態的 retry topic 跟 DLQ 設計比較

判讀徵兆

以下訊號出現時，應該回讀本案例：

• Consumer 的 processing lag 在特定時段突然升高、但訊息產生速率沒變
• 同一條訊息的 retry 佔據 consumer 的大部分處理時間
• Requeue 後訊息立刻又被同一個 consumer 取到、進入 retry 迴圈
• DLQ 中的訊息堆積、沒有定期審視跟 replay 的機制
• Retry 策略只有 client 端 backoff、沒有 queue 拓樸層面的隔離

引用源

• Delaying Messages with RabbitMQ at Indeed
• Get a Job 35 Million Times a Day Using RabbitMQ (talk)

觀察

單一 RabbitMQ cluster 作為所有服務之間的通訊中樞、自家 Hutch（Ruby lib）2013 從 production 抽出開源。

判讀

routing key 格式 service.subject.action（如 paysvc.payment.chargedback）、單一 topic exchange、JSON 序列化（多語言可讀）。揭露小規模單 cluster 可以用「routing key 命名規範」取代複雜 exchange 拓樸。

對應大綱

RabbitMQ 進階主題：Exchange types 與 routing 設計 / 多 vhost（單 vhost 服務 mesh 的反向案例）。

下一步路由

回 RabbitMQ vendor 頁 與 3.C23 Bloomberg（規模化後的對照）。

引用源

• Hutch: Inter-Service Communication with RabbitMQ

觀察

Communication platform 用 RabbitMQ cluster、跑在 EC2 / Docker container 上、用 supervisord 並行 sidekick + RabbitMQ。AWS 帳號限制每 region 5 個 Elastic IP。

判讀

自建 sidekick 服務查 AWS API 動態識別 cluster、指定最老 instance 當 master、master 死後晉升下一個最老 node。跨版本升級用 federation 上游接到新 cluster 過渡。揭露「cluster master selection」跟「IP 限制」是雲端部署的早期關鍵限制。

對應大綱

RabbitMQ 進階主題：Erlang clustering + network partition / Federation + Shovel / RabbitMQ Cluster Operator（K8s 之前的雲端 cluster 治理）。

下一步路由

回 RabbitMQ vendor 頁 與 3.1 broker basics。

引用源

• Rabbit in the Cloud (Zalando Engineering)

觀察

訊息順序對某些業務流程關鍵、但全局排序代價高。WeWork 採固定數量 queue + 用 account ID hash 路由到特定 queue。

判讀

每個 queue 一個 SideKiq worker + exclusive consumer 保證單帳戶順序。文後發現 RabbitMQ Consistent Hashing plugin 已內建類似機制（類似 Kafka 分區）。揭露 partition-level ordering 不是 Kafka 專屬、在 broker model 可用 hash exchange 達成。

對應大綱

RabbitMQ 進階主題：Exchange types / Prefetch + consumer 併發（partition-level ordering 模式）。

下一步路由

回 RabbitMQ vendor 頁 與 Kafka vendor 頁（partition + key 對照）。

引用源

• WeWork’s “Good Enough” Order Guarantee

觀察

從 Unicorn 切到 Puma 後遇到 ConnectionClosedError、根因是快取 Bunny channel 在多執行緒間共享。

判讀

AMQP channel 不應跨執行緒共用、改用 connection_pool gem 管理 channel pool。揭露 AMQP 不是 stateless HTTP-style client、channel 是 statefull 物件、多 thread 模型要特別處理。

對應大綱

RabbitMQ 進階主題：Prefetch + consumer 併發（client library 層的 connection / channel 邊界）。

下一步路由

回 RabbitMQ vendor 頁 與 3.4 consumer 設計。

引用源

• Bunny Threads in Puma at WeWork

業務背景

Runtastic 是 Adidas 旗下的健身追蹤平台，使用者透過 app 記錄跑步、騎車、重訓等運動資料。2020 年 COVID-19 lockdown 期間，居家運動需求爆增，平台的 concurrent user 數量在數週內翻倍。

Runtastic 的後端架構是 microservice 架構，RabbitMQ 是服務間訊息傳遞的核心。運動資料記錄、通知推送、社交功能（好友排行、挑戰）、analytics 事件都透過 RabbitMQ 的 queue 串接。

技術挑戰：Mirroring 的隱藏網路成本

Runtastic 的 RabbitMQ cluster 使用 mirrored queue（ha-mode: all）確保訊息在 broker 故障時不遺失。Mirrored queue 把每條訊息同步複製到 cluster 中所有 node — 3 node cluster 代表每條訊息的網路傳輸量是原始大小的 3 倍。

日常流量下，mirroring 的額外網路負載在 cluster 的頻寬容量之內，效能影響不明顯。但 lockdown 後流量翻倍時，mirroring 的網路負載跟著翻倍 — 更準確地說是翻 2×N 倍（流量 2 倍 × mirror 數 N）。

Runtastic 的 cluster 使用了共享的網路元件（network switch / load balancer），mirroring 的流量把共享網路元件的頻寬壓到極限。表現是 broker 間的 mirroring 延遲上升 → publisher confirm 延遲上升 → producer 端的 publish latency 從毫秒跳到秒級 → 上游服務開始 timeout。

問題的隱蔽性在於：日常監控只看 broker 的 CPU、memory、disk，沒有把 inter-node network throughput 作為關鍵指標。網路瓶頸在 broker-level metric 上的表現是「publish confirm 變慢」，容易被誤判為 broker 過載而非網路飽和。

解法

Performance test 定位瓶頸

Runtastic 在事件發生後用 performance test 重現問題。測試揭露了 mirroring 流量跟 broker 間網路頻寬的關係 — 把 message rate 從日常的 X 推到 2X 時，inter-node traffic 超過 switch 容量，publish confirm latency 開始非線性增長。

Performance test 的關鍵是把 inter-node network throughput 加入監控維度。RabbitMQ 3.8 的 Prometheus integration 提供了 rabbitmq_raft_term_total、rabbitmq_channel_messages_published_total 等指標，但 inter-node bandwidth 需要從 OS 層（node_exporter 的 network bytes）或 switch 層取得。

調整 mirroring 配置

Runtastic 從 ha-mode: all（所有 node 都 mirror）調整為 ha-mode: exactly, ha-params: 2（只 mirror 到 2 個 node）。這把每條訊息的網路複製量從 N 倍降到 2 倍，在可靠性（2 個 copy 可以容忍 1 node failure）跟網路成本之間取得平衡。

對可靠性要求最高的 queue（交易相關），維持 ha-mode: all 但把這些 queue 移到頻寬更高的專屬 network segment。

遷移到 Quorum queue 的動機

Mirrored queue 的另一個問題是同步機制 — 新 mirror 加入時需要全量同步（sync），sync 期間 queue 可能暫停接受新訊息。RabbitMQ 3.8 引入的 Quorum queue 用 Raft consensus 取代 mirrored queue 的 GM（Guaranteed Multicast），在網路效率跟故障恢復上都有改進。

Runtastic 的案例是「為什麼應該評估從 mirrored queue 遷到 quorum queue」的典型動機 — mirrored queue 的網路成本跟同步行為在規模化時成為瓶頸。

取捨

回寫教材的連結

• 3.1 broker basics：broker 的 replication 跟 network 成本的關係
• RabbitMQ vendor 頁：mirrored queue vs quorum queue 的詳細比較
• RabbitMQ queue types：Classic / Mirrored / Quorum / Stream 四種 queue type 的取捨
• 4.11 telemetry pipeline：broker 的 inter-node 網路作為 pipeline 健康指標

判讀徵兆

以下訊號出現時，應該回讀本案例：

• RabbitMQ cluster 使用 ha-mode: all 且 node 數量 > 3
• Publish confirm latency 在流量上升時非線性增長
• Broker 的 CPU / memory / disk 指標正常但 publish 變慢
• Broker 間的 network traffic 佔比超過 cluster 總頻寬的 50%
• 新 mirror 加入時 queue 出現暫停或大量延遲

引用源

• Runtastic RabbitMQ Performance Case Study

觀察

Pulse 是 Mozilla 自動化 / 基礎設施工具間的 managed RabbitMQ cluster、用 AMQP 0-9-1 + RabbitMQ 擴充、由 CloudAMQP 託管於 pulse.mozilla.org:5671（AMQP over TLS）。

判讀

技術上不需 vhost、改用權限限制 + 命名前綴（exchange/<username>/*、queue/<username>/*）做隔離。PulseGuardian 跑在 Heroku 管理使用者 / queue / exchange。揭露多租戶隔離不一定要 vhost、權限粒度可以拉到 resource naming 層。

對應大綱

RabbitMQ 進階主題：多 vhost + 多租戶（反向案例：用 ACL + naming 取代 vhost）。

下一步路由

回 RabbitMQ vendor 頁 與 3.C23 Bloomberg vhost 多租戶（對照）。

引用源

• Mozilla Pulse Wiki
• Pulse API

觀察

LoyaltyLion 跑數千個 RabbitMQ queue、用 rabbitmqctl 跑 recurring script 抓 queue 資訊、透過 statsd 送到 Datadog。

判讀

大規模 queue 拓撲下管理 plugin API 不夠用、需自寫採集腳本。揭露 queue 數量上萬時、原生 monitoring 介面（HTTP API、Management UI）會變成瓶頸、需要 metrics agent 模式。

對應大綱

RabbitMQ 進階主題：Prefetch + consumer 併發（大規模 queue topology 的監控議題）/ RabbitMQ Cluster Operator（運維邊界）。

下一步路由

回 RabbitMQ vendor 頁 與 4 觀測模組。

引用源

• Monitoring Thousands of RabbitMQ Queues with Datadog

觀察

World of Tanks server 全 Linux、用 RabbitMQ 作為 web service stack 核心。每場戰鬥結束後玩家 tank dossier 寫入 message queue、讓 game portal 顯示最新統計而不增加 game server load。

判讀

Queue 是 game server 與 portal 的解耦邊界、subscription 也走 RabbitMQ。揭露遊戲場景的「戰後事件 burst」適合用 queue 吸收、不該打到 game server 內部狀態。

對應大綱

RabbitMQ 進階主題：Federation + Shovel（多 region game server 同步）/ 多 vhost + 多租戶（多遊戲共用 broker）。

下一步路由

回 RabbitMQ vendor 頁 與 3.4 consumer 設計。

引用源

• Wargaming Mobilizes with Linux and Open Source (Linux Foundation)
• Wargaming Public API

業務背景

Netlify 是靜態網站跟 serverless function 的部署平台，服務 70,000+ 網站、近月 10 億 page view。基礎設施橫跨 Rackspace、AWS、GCP、Digital Ocean 四個雲端供應商。每個服務節點都會產生 metrics 跟 logs，需要一條統一的資料路徑把這些訊號從各地收集到中央觀測系統。

技術挑戰

跨雲統一資料平面

四個雲的服務各自有不同的網路拓樸跟存取方式。觀測資料需要跨雲收集到同一個目的地（Elasticsearch），但直接讓每個服務 HTTP POST 到 Elasticsearch 會有連線管理、背壓、格式轉換的問題分散在每個服務裡。

Netlify 需要一個中介層 — 各服務把 metrics / logs 推到中介層，中介層負責 fan-out 到下游消費者（Elasticsearch、即時 dashboard、告警系統）。

選型：NATS vs RabbitMQ

Netlify 評估了 RabbitMQ 跟 NATS。RabbitMQ 在功能上更完整（持久化 queue、DLQ、ack 機制），但 Netlify 的觀測資料場景有三個特性讓 NATS 更合適：

• 資料可丟：metrics 跟 logs 是 best-effort 的觀測資料，遺失幾秒的資料不影響業務 — 持久化保證帶來的運維成本大於收益
• Fan-out 是主要模式：同一份資料要被多個消費者訂閱（Elasticsearch、即時 tail、告警），NATS 的 subject-based pub/sub 天然支援，RabbitMQ 需要設 exchange + 多個 binding
• 部署極簡：NATS server 是單一 binary、零依賴、幾秒鐘啟動，跨四個雲部署時每個雲跑一個 NATS node 的運維成本遠低於 RabbitMQ cluster

解法與取捨

架構

Netlify 用 Core NATS（非 JetStream）搭建觀測資料平面：

• Producer 端：用 logrus 的 NATS hook 讓所有 Go 服務的 structured log 自動推到 NATS subject；另用 log-tail 工具從 file-based log 讀取推送
• Consumer 端：一個 elastinats 消費者訂閱 NATS subject、批次寫入 Elasticsearch；其他消費者可以各自訂閱同一個 subject 做即時處理

Subject 的命名用階層式結構（例如 logs.production.api），讓消費者可以用 wildcard 訂閱整個子樹（logs.production.*）或特定服務。

取捨

Core NATS 的 fire-and-forget 語意在觀測資料場景是有意的選擇 — 觀測資料的價值隨時間快速衰減，遺失一秒鐘的 metrics 不影響趨勢判讀。如果場景需要持久化（例：audit log、交易事件），Core NATS 就不適合，需要 JetStream 或其他有持久化保證的 broker。

回寫教材的連結

• 3.1 broker basics：Core NATS 的 fire-and-forget 是 broker 可靠性光譜的一端（at-most-once），Kafka 跟 RabbitMQ 在另一端（at-least-once / durable）
• NATS vendor 頁：Core NATS vs JetStream 的選型判準 — 本案例是純 Core NATS 的代表場景
• 4.11 telemetry pipeline：Netlify 的 NATS 資料平面在觀測 pipeline 架構中扮演 collector 跟 storage 之間的 transport 層

判讀徵兆

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

• 觀測資料（metrics / logs）需要跨多個雲或多個 datacenter 收集到中央系統
• 現有的 broker（RabbitMQ / Kafka）在觀測資料場景的運維成本跟資料價值不成比例
• Fan-out 是主要消費模式 — 同一份資料需要被多個下游系統訂閱
• 對 message delivery 的可靠性要求是 best-effort 而非 at-least-once

引用源

• Why Netlify chose NATS

觀察

Form3 服務 Tier-1 銀行（含 Mastercard、Square 等）、要求 500ms 端到端 SLA、AWS SNS/SQS 約 300ms 延遲吃掉預算。在 Faster Payments 機房資源受限下、用 NATS + JetStream 替換 legacy pub/sub bus、達到約 6× 延遲改善並做到「AWS 整個 region 掛掉時不喪失處理能力」。

判讀

用 JetStream 的 Leaf Node 做跨雲橋接、把 on-prem Faster Payments 機房跟雲端 cluster 連起來。揭露金融支付對端到端 latency 預算的硬要求逼出特定 broker 選型、不是「Kafka / SQS 通用化」。

對應大綱

NATS 進階主題：Cluster + Supercluster + Leaf node / JetStream stream 設計。

下一步路由

回 NATS vendor 頁 與 3.C1 Meta FOQS（跨區對照）。

引用源

• How Form3 Built a Multi-Cloud Low-Latency Payments Service with NATS JetStream (Synadia blog)

觀察

Intelecy 在工廠端 gateway 接「數萬個 sensor」、要求 < 2 秒往返延遲做即時 ML 推論、需要多租戶安全隔離與雲端無鎖定方案。Gateway 把 process data 寫進 Synadia Cloud topic。

判讀

從 BoltDB 本地快取 → JetStream 持久化的演進、揭露「無 durable layer 時 edge gateway 自己要做存儲、加 JetStream 後可放掉本地 BoltDB」的決策訊號。

對應大綱

NATS 進階主題：JetStream stream 設計 / Subject-based ACL + 多租戶（sensor 隔離）。

下一步路由

回 NATS vendor 頁 與 3.C37 MachineMetrics（同類對照）。

引用源

• How Intelecy Optimizes Factory Processes with NATS, NGS and JetStream

觀察

跨「數百個客戶廠區、數千台機台」的 Industrial IoT、單機產出最高 1000 Hz 採樣、工廠網路斷斷續續、Kinesis 等 cloud-only 工具無法跑在資源受限 edge 上。

判讀

用 Leaf Node 做 hub-and-spoke 把邊緣設備串到雲端、Edge 端用 JetStream 做本地持久化（取代 SQLite）抵抗網路斷線、用 KV store 做 config / 短期 cache、Object Store 派發 WASM 模組、Decentralized Auth 隔離客戶。揭露「broker 的功能集合」決定它能不能取代多套 edge 工具。

對應大綱

NATS 進階主題：Cluster + Supercluster + Leaf node / JetStream KV + Object Store / Subject-based ACL + 多租戶。

下一步路由

回 NATS vendor 頁 與 3.C36 Intelecy（同類對照）。

引用源

• MachineMetrics Customer Story (Synadia)

觀察

Clarifai 做 custom model 訓練、任務從幾秒到幾分鐘、原本同步呼叫遇到 rolling deployment 會掉訊息。三週內把一個服務遷到 NATS、5 個月內擴展到 5 個服務、每日 100k+ 訊息、100% uptime。

判讀

用 NATS Streaming 的 at-least-once delivery + queue subscription group 做 worker pool、每個微服務連到三個獨立 NATS Streaming 實例做 fanout 隔離。揭露 ML 任務的長尾處理時間特別需要 at-least-once + redelivery、不能容忍 rolling deploy 掉訊息。

對應大綱

NATS 進階主題：JetStream consumer 設計（NATS Streaming 是前身）/ Queue groups。

下一步路由

回 NATS vendor 頁 與 3.4 consumer 設計。

引用源

• How Clarifai Uses NATS and Kubernetes for Machine Learning

觀察

Choria 是 Puppet MCollective 的現代化替代品、目標管理數萬到數十萬節點的 fleet 同時下指令。評估過多個 broker、選 NATS 因為「單 binary、無 Zookeeper 依賴、Ruby client 品質好」、實測「單 server 300MB RAM 管 2000+ 機器」、4GB 節點可達 50 萬 server。

判讀

MCollective 的 fire-and-forget RPC 語意正好對應 NATS Core 的 stateless best-effort + request-reply pattern、用 wildcard subject + queue group 做 parallel scatter-gather RPC。揭露 server orchestration 場景不需要 persistence、Core NATS 已足夠。

對應大綱

NATS 進階主題：Request/Reply pattern / Queue groups / Cluster + Supercluster + Leaf node（Choria Federation Broker = 跨地理 federation）。

下一步路由

回 NATS vendor 頁 與 3.1 broker basics。

引用源

• NATS for the Marionette Collective (Choria)
• Choria Architecture Docs

觀察

Resgate 把 NATS subject 暴露成 REST + WebSocket、客戶端跨多 Resgate 實例自動同步狀態、事件延遲 < 1ms。需要同時支援 pub-sub 跟 request-reply、選 NATS 因為「performance、simplicity、兩種模式都原生支援」。

判讀

subject 設計遵循 get.{service}.{resource} / event.{service}.{resource}.{event-type} 的命名規約、是「subject 階層當 schema」的典型範例。揭露 subject 命名是 NATS 的 API contract 起點、不是隨意命名。

對應大綱

NATS 進階主題：Request/Reply pattern / Subject-based ACL + 多租戶（subject hierarchy 即 access control 邊界）/ Core NATS vs JetStream（純 Core）。

下一步路由

回 NATS vendor 頁 與 3.C26 GoCardless Hutch routing key（命名規約對照）。

引用源

• Introducing Resgate

觀察

i-flow 是工業數據整合平台、每日 4 億筆 data operation、提供 200+ OT/IT 系統 connector、客戶含 Fortune 500 工廠（Bosch、Sto、Lenze）。

判讀

用 NATS 當 OT/IT 跨層整合 bus、邊緣端負責 connect / harmonize / publish。揭露多工廠場景該用 leaf node hub-and-spoke、不該每工廠自管 cluster。注意：此案例技術細節較淺、引用時要補其他案例的具體 stream / consumer 設計。

對應大綱

NATS 進階主題：Cluster + Supercluster + Leaf node（多工廠 leaf node 連 central）。

下一步路由

回 NATS vendor 頁 與 3.C37 MachineMetrics（技術細節更深的對照）。

引用源

• i-flow Case Study

觀察

Bitso 的 Order Engine 微服務需要 thousands of messages/sec/stream + 亞毫秒延遲、撐住 BTC 價格暴動的流量尖峰；先後評估 Kafka（latency）跟 SQS（vendor lock-in + latency）後選 Redis Streams、團隊本來就熟 Redis、已在 mission-critical service 跑超過半年。

判讀

自建 “Reliable Redis Streams” 抽象層（StreamRedisOperations adapter / ReliableStream interface / MessageReadingLoop）封裝 readMessages + readPendingMessages、加上 Redis Streams 沒有原生支援的 DLQ（N 次 retry 後路由）、走 idempotent processing 接受重複勝過遺失。揭露 Redis Streams 是「資料結構」、不是「broker 系統」、可靠性責任在 application 層。

對應大綱

Redis Streams 進階主題：Consumer group + PEL / XCLAIM + 失敗接管 / Sentinel + Cluster 可靠性。

下一步路由

回 Redis Streams vendor 頁 與 3.4 consumer 設計。

引用源

• The Redis Streams We Have Known and Loved

業務背景

Arcjet 是 security / bot detection 平台，處理每個 HTTP request 的安全判斷。核心需求是 low-latency 的請求處理 — 安全判斷要在幾毫秒內完成，不能拖慢使用者的 request。

系統架構中有一段 event-driven pipeline 負責把安全事件從 detection layer 傳遞到 analytics 跟 alerting。原本評估用 Kafka 做這段 pipeline，但 managed Kafka 的年費落在六位數美金 — 對 Arcjet 的流量規模跟業務階段，這個成本不合理。

Arcjet 的基礎設施已經有 Redis 做 cache。把 Redis 從純 cache 升級到 cache + Streams，利用既有的 Redis infrastructure 承擔 event pipeline，總成本約 $1k/year。

技術挑戰

Redis Streams 沒有自動 retention

Kafka 的 retention 是內建功能 — 設定 log.retention.hours 後 broker 自動刪除到期資料。Redis Streams 沒有內建的自動 retention — stream 資料會持續累積，直到手動 XTRIM 或 XDEL。

在生產環境下，不處理 retention 意味著 Redis 的記憶體持續成長，最終觸發 eviction policy 或 OOM。對 Arcjet 來說 Redis 同時做 cache 跟 Streams，Streams 的記憶體成長會擠壓 cache 的可用空間。

Consumer group 進度追蹤

Redis Streams 的 consumer group 會追蹤每個 consumer 的讀取進度（last delivered ID）。做 XTRIM 時需要確保不刪除尚未被所有 consumer group 確認的訊息 — 否則 consumer 會丟失未處理的事件。

Kafka 的 log compaction 跟 retention 自動處理這個問題（consumer offset 以前的 segment 才會被清理）。Redis Streams 需要 application 自己確認所有 consumer group 的進度，再決定 trim 的位置。

單機 Redis 的可靠性邊界

Redis 的持久化機制（RDB snapshot + AOF）提供的是 best-effort 的持久性，跟 Kafka 的 replication-based 持久化保證不同。Redis crash + restart 時，AOF 的最後幾筆寫入可能遺失（取決於 appendfsync 設定）。

對 Arcjet 的安全事件場景，偶爾丟失幾筆事件可以接受（security detection 的結果是即時判斷，事後的 analytics 容忍小量遺失）。如果場景是金融交易或 audit log，這個可靠性邊界就不夠。

解法與取捨

自建 Janitor process

Arcjet 自寫了一個 Janitor process 處理 Redis Streams 的 retention：

1. 定期檢查每個 stream 的長度（XLEN）
2. 查詢所有 consumer group 的 pending entry list（PEL）跟最後確認位置
3. 計算安全的 trim 位置（所有 consumer group 都已確認的最舊 ID）
4. 執行 XTRIM stream MINID <safe-id> 刪除已確認的舊資料

Janitor 的執行頻率根據實際處理速度（~100 msgs/min）設定 — 不需要非常頻繁，但不能完全不跑。

取捨

適用邊界

Redis Streams 取代 Kafka 的適用邊界：

• 流量規模：每分鐘數百到數千筆（超過每秒數萬筆需要 Redis Cluster 或多 stream）
• 持久化要求：容忍偶爾丟失少量訊息（best-effort）
• 已有 Redis：不需要額外部署 Redis、利用既有 infrastructure
• Kafka 功能不需要：不需要 Kafka Connect、Schema Registry、long-term retention、跨 region replication

超過這些邊界時，Redis Streams 的自建成本（Janitor + 監控 + retention 治理 + 可靠性補償）會逐漸接近 managed Kafka 的費用，成本優勢消失。

回寫教材的連結

• Redis Streams vendor 頁：XCLAIM / PEL recovery 的進階主題
• Kafka vendor 頁：成本對照 — Kafka 的固定成本高但功能完整
• 3.2 durable queue：Redis Streams 的持久化機制跟 Kafka 的 replication 在 durability 光譜上的位置
• 3.1 broker basics：broker 選型時成本是一級決策維度

判讀徵兆

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

• Managed Kafka 的月帳單跟實際流量量級不成比例（低流量但高成本）
• 已有 Redis infrastructure、考慮把 event pipeline 合併到 Redis
• Event pipeline 的流量在每秒數百筆以下、持久化要求是 best-effort
• Redis 記憶體持續成長但不確定 Streams 的 retention 有沒有正確執行

引用源

• Replacing Kafka with Redis Streams

觀察

Harness 為 CD 微服務之間的 async state transfer 採用 Redis Streams、避開「每個 service 都要知道怎麼跟其他 service 講話」的 brittle HTTP 模式；初始規模 a few thousand msgs/min、Kafka 在此規模 overkill、又能複用已存在的 Redis 基建。

判讀

落地後揭露三類問題：監控缺口（自寫 app 追 consumer lag）、需要主動 MAXLEN truncation、head-of-line blocking 要用 XAUTOCLAIM 重派並設計 redelivery 策略。揭露「Redis Streams 適合中小規模」這個聲明、實際包含三件 production work。

對應大綱

Redis Streams 進階主題：Consumer group + PEL / XCLAIM + 失敗接管 / Memory + retention 取捨。

下一步路由

回 Redis Streams vendor 頁 與 3.5 紅隊章。

引用源

• Event-Driven Architecture with Redis Streams

觀察

Klaxit 用 Redis Streams 處理 Heroku Logplex 匯流的 log、自動偵測並修復 Heroku 平台層 perf 問題（在使用者察覺前）；正式 production 跑超過 6 個月、是團隊第一個 Rust project。

判讀

揭露 high-throughput log ingestion 對 Redis Streams 的壓力：用 consumer group 分流到多個 Rust worker、需要長時間穩定運轉。揭露 client library 品質決定 Redis Streams 在小眾語言（Rust）的可行性。

對應大綱

Redis Streams 進階主題：XADD / XREAD / XREADGROUP 操作 / Consumer group + PEL。

下一步路由

回 Redis Streams vendor 頁 與 3.4 consumer 設計。

引用源

• Consuming High-Throughput Redis Streams with Rust

觀察

Learning.com 把 microservice 之間的 event store 放 Redis 上、一年內累積到 GB/週的 memory 成長、AOF fsync + EBS 磁碟 I/O 變成 latency 痛點。

判讀

揭露「Redis 不適合長期事件儲存」的退場路徑：event 移到 PostgreSQL、Redis 留做訊息佇列 + snapshot；中途靠 syncTimeout 調整、提升 IOPS、調整 AOF fsync 緩解。揭露 broker 選型要看「長期存儲是 source-of-truth 還是 transient」。注意：此文討論的是 Redis-as-event-store 整體、Streams 是其中一塊、引用時要小心區分。

對應大綱

Redis Streams 進階主題：Memory + retention 取捨 / Sentinel + Cluster 可靠性（持久化選型）。

下一步路由

回 Redis Streams vendor 頁 與 3.3 outbox pattern。

引用源

• A Year with Redis Event Sourcing - Lessons Learned

觀察

PHP 雙微服務之間的可靠通訊、Kafka 在 PHP 生態工具薄弱、團隊無 Kafka 經驗、production 跑數月後寫此文；明確覆蓋 XADD / XREADGROUP / consumer group / MAXLEN / MINID / XDEL / XACK / XACKDEL（Redis 8.2+）/ XTRIM。

判讀

揭露 in-memory 訊息的 payload 限制：用 payload compression + S3 hybrid storage（大 payload 存 S3、stream 只放 reference）；用 MAXLEN/MINID 控制 stream 成長。揭露 broker 選型常被「語言生態 client 品質」主導、不是純技術 feature。注意：作者是個人工程師、production 經驗但非知名公司。

對應大綱

Redis Streams 進階主題：XADD/XREAD/XREADGROUP 操作 / Retention (MAXLEN/MINID) / Memory + retention 取捨。

下一步路由

回 Redis Streams vendor 頁 與 3.C16 Robinhood Faust（語言生態對照）。

引用源

• Beyond the Hype: Why We Chose Redis Streams Over Kafka for Our Microservices

觀察

Airbnb 構建 Dynein 分散式延遲任務排程系統取代 Resque（受限於單 Redis 實例）。明確選 SQS、利用 at-least-once delivery、dead letter queue、individual message acknowledgment、access control 與 encryption-at-rest。每個 scheduler instance 達 ~1000 QPS、可水平擴展。

判讀

at-least-once 對工作排程「不丟資料」假設足夠、SQS wrap DynamoDB 處理 > 15 分鐘 delay、DLQ 分離「短暫失敗」與「永久毒訊息」。揭露 managed queue 在工作排程的取捨：trade ordering 換 scaling。

對應大綱

SQS 進階主題：Standard vs FIFO / DLQ 設計。

下一步路由

回 SQS vendor 頁 與 3.2 durable queue。

引用源

• Dynein: Building a Distributed Delayed Job Queueing System

觀察

Airbnb 的 Inspekt 隱私資料掃描系統用 SQS task queue 派發 scan task（每 table/object/app 一個 message）、Scanner nodes 水平 pull。“each message reappears N times back into the queue until a scanner node deletes it” 是 visibility timeout 在實戰的應用。

判讀

用 message 重現次數做 retry budget、scanner 失敗時不用自管 retry table。揭露 SQS 的「不刪除即重現」是設計、不是 bug、可以當隱式 retry 機制用。

對應大綱

SQS 進階主題：Visibility timeout + in-flight messages。

下一步路由

回 SQS vendor 頁 與 3.4 consumer 設計。

引用源

• Automating Data Protection at Scale Part 2

業務背景

Capital One 是美國大型金融機構，tech blog 公開分享了 SQS + Lambda 的 event-driven 架構實踐。金融場景的 message 處理對正確性要求極高 — 重複處理一筆交易跟遺失一筆交易的代價都是具體的金錢損失。

SQS 是 AWS 原生的 managed queue，Lambda 是 serverless compute。兩者搭配的 event source mapping 是 AWS 上最常見的 event-driven 入門架構 — 看起來簡單（SQS → Lambda 自動觸發），但 visibility timeout 跟 Lambda scaling 的互動有不少實務細節。

技術挑戰

Visibility timeout 的雙邊風險

SQS 的 visibility timeout 定義了「consumer 取走訊息後，其他 consumer 多久之後才能再看到這筆訊息」。它是 SQS 的核心容錯機制 — consumer 處理失敗（crash、timeout）時，visibility timeout 到期後訊息重新出現在 queue 裡，讓其他 consumer 接手。

Timeout 太短：consumer 還在處理中、visibility timeout 已到期、另一個 consumer 取走同一筆訊息開始處理 — 重複處理。金融場景的重複處理可能導致重複扣款或重複退款。

Timeout 太長：consumer 處理失敗、需要等很久 visibility timeout 才到期、訊息才重新出現 — retry 延遲。原本幾秒就能被其他 consumer 接手的訊息，要等 15 分鐘才 retry。

Capital One 的實務建議是 visibility timeout 設為「最大預期處理時間 + 少量緩衝」。例如：最大處理時間 30 秒 → visibility timeout 設 45 秒。

Lambda event source mapping 的 scaling 行為

Lambda 跟 SQS 的整合透過 event source mapping — Lambda 服務自動從 SQS long polling 取訊息、觸發 Lambda function。使用者不需要自己寫 polling 邏輯。

Capital One 揭露的 scaling 行為跟「Lambda 自動擴展」的直覺不同：

• 初始狀態：Lambda 啟動 5 個 long polling connection（poller）
• Scale up：每分鐘最多新增 60 個 poller instance（每個 instance 處理一批 message）
• 上限：最多 1000 個並行 batch

這意味著突發流量（queue 瞬間湧入大量訊息）的消化速度不是即時的 — Lambda 需要數分鐘才能 scale 到足夠的並行度。在這段 ramp-up 期間，queue depth 會持續增長。

Batch size 跟 visibility timeout 的互動

Lambda event source mapping 預設 batch size = 10 — 一次取 10 筆訊息、用一個 Lambda invocation 處理。如果 batch 中的某一筆處理特別慢，整個 batch 的處理時間會被拉長。

Visibility timeout 要覆蓋整個 batch 的處理時間（包含最慢的那一筆），否則 batch 還在處理中、早期取走的訊息 visibility timeout 到期、被其他 poller 重新取走 — 導致重複處理。

解法與取捨

Idempotency 作為安全網

Visibility timeout 無法完全避免重複處理（網路分區、Lambda timeout 等邊界條件）。Capital One 的做法是在 Lambda function 內實作 idempotency — 用 message ID 做去重，確保同一筆訊息被多次處理時結果相同。

Idempotency 把 visibility timeout 的精確度要求降低 — 即使偶爾重複處理，業務結果仍然正確。Visibility timeout 仍然需要合理設定（降低不必要的重複 invocation 成本），但 idempotency 是「即使設錯也不會造成業務錯誤」的安全網。

回寫教材的連結

• SQS vendor 頁：visibility timeout、in-flight limit、Lambda event source 的進階主題
• 3.6 processing recovery semantics：at-least-once 語意下的 consumer 端 idempotency
• 3.2 durable queue：visibility timeout 是 SQS 的 delivery guarantee 機制
• 3.8 queue consumer retry replay handoff：DLQ + maxReceiveCount 的 retry 升級策略

判讀徵兆

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

• SQS + Lambda 架構中出現訊息重複處理（CloudWatch 的 ApproximateNumberOfMessagesNotVisible 跟 NumberOfMessagesReceived 比例異常）
• Lambda function 的 timeout 跟 SQS visibility timeout 的關係沒有明確設計
• 突發流量時 queue depth 持續增長、Lambda 的 concurrent execution 沒有立刻跟上
• Batch processing 中的慢訊息拖慢整個 batch、造成 visibility timeout 到期

引用源

• Using AWS Solutions for Event-Driven Serverless Architectures

觀察

Atlassian 內部 event bus StreamHub 底層用 Kinesis、但「每個 consumer 自己準備 SQS queue 接收 event」。JiRT 即時服務透過此模式把輪詢式（~1 min）改成 event-driven（秒級）。

判讀

在 Kinesis 上面疊 SQS 讓 consumer 各自設定 retention、各自獨立 visibility timeout。揭露「stream + per-consumer queue」是 fan-out 場景的常見複合 pattern、不是 streaming vs queue 二選一。

對應大綱

SQS 進階主題：Standard vs FIFO / SQS 作為 fan-out subscriber。

下一步路由

回 SQS vendor 頁 與 Kafka vendor 頁（streaming + queue 對照）。

引用源

• Using an Event-Driven Architecture to Improve Jira Software Responsiveness

觀察

Nielsen 每日處理 25 TB / 30 billion event。架構用兩個 SQS queue：work queue（待處理工作項）+ completion queue（回報完成）。Lambda 從 DB 拉檔案、組成 work item 推進 work queue、EKS pod 拉取處理、處理完寫 completion queue。基於 queue depth 自動擴 pod。

判讀

不用直接 Lambda invoke（pod 上跑長時間 Spark workload）、queue depth 當 backlog signal driving autoscale。揭露長 workload 場景該用 pod + queue depth、不是 Lambda function。

對應大綱

SQS 進階主題：CloudWatch metric + alarm / Standard queue / 長 workload autoscaling。

下一步路由

回 SQS vendor 頁 與 3.C22 Trivago KEDA（lag-based autoscale 對照）。

引用源

• How Nielsen Uses Serverless Concepts on Amazon EKS for Big Data Spark Workloads

觀察

FINRA 金融監管機構、處理 broker-dealer 上傳大檔。Large File Service 用 S3 → SQS 通知模式：使用者上傳完 loading dock bucket、S3 推 SQS message 給 LFS、移檔後再推 “file available” SQS message 給下游。

判讀

S3 通知是 SQS 最經典 trigger、KMS + bucket policy + queue 權限的合規場景（金融業要保留稽核軌跡）。揭露金融場景的 IAM 設計不是一道權限、是多層稽核軌跡。

對應大綱

SQS 進階主題：SQS + Lambda event source / IAM + Cross-account。

下一步路由

回 SQS vendor 頁 與 7 security 模組。

引用源

• FINRA Large File Service

觀察

Twitch 內部 Event Bus 發佈 ~1660 events/sec 到 SNS。EventSub（給第三方應用訂閱 Twitch 事件）用 SQS 接收 async notification、再由 Dispatcher fan-out 給各訂閱者。

判讀

fan-out 後每個 consumer 要自己一個 queue。揭露 SNS → SQS 是 AWS 生態的 fan-out 標配、SQS 是第三方訂閱的 buffer 層、Dispatcher 是 application 級別的分發責任。

對應大綱

SQS 進階主題：Standard queue + SQS + Lambda / SNS-SQS fan-out。

下一步路由

回 SQS vendor 頁 與 3.C51 Atlassian JiRT（subscription 對照）。

引用源

• Twitch State of Engineering 2023

觀察

SmugMug 用 SQS 兩種模式：(1) backfill — script 推 DynamoDB scan-segment 指令進 SQS、Lambda 拉取做平行掃描寫 OpenSearch、(2) 鏡像查詢 — production query 推副本 SQS、Lambda replay 到 replica domain。每小時可 index > 1 billion document、不影響 production。

判讀

SQS 作為「workload generator」分散式平行化、不需協調 worker 數量。揭露 SQS 不只是「事件 queue」、也是「並行任務分散」的協調基礎。

對應大綱

SQS 進階主題：Standard queue / Long polling / SQS + Lambda event source。

下一步路由

回 SQS vendor 頁 與 3.4 consumer 設計。

引用源

• SmugMug’s Durable Search Pipelines for Amazon OpenSearch Service

觀察

PostNL（荷蘭最大物流商、每天 6.9M 信件 + 1.1M 包裹）的 Event Broker E-commerce 系統每天處理 ~10M message。完整列出 SQS 配置：每 producer/consumer 隔離 stack（最小爆炸半徑）、3 天 replay via EventBridge、exponential backoff with jitter、24 小時內最多 retry 100 次、final DLQ 允許 consumer 自己 redrive。max receive count 設 1 觸發 DLQ 告警。

判讀

「每 producer/consumer 隔離 stack」是 mission-critical 系統的 blast radius 設計、不只是 queue 配置。揭露 production-grade SQS 設計含三件事：隔離 + retry 政策 + redrive 流程。

對應大綱

SQS 進階主題：DLQ 設計 / CloudWatch alarm / Cost 模型。

下一步路由

回 SQS vendor 頁 與 3.C9 反例：語義誤配。

引用源

• Designing a Mission-Critical Serverless Application for High Resilience

觀察

Lob（programmatic mail API）原本用 bbc/sqs-consumer 但被鎖在 AWS SDK v2。他們 fork 出 @lob/sqs-consumer：支援 SDK v3（模組化 import 縮 bundle、TypeScript 一級支援、async/await）、修正原 library 對 FIFO queue 的 bug。SQS 用在 Lob API 跟其他內部 service。

判讀

不能只靠 SDK 原生 API、SDK 升級會逼出 library 維護議題。揭露「FIFO queue 跟 standard queue 的 client 行為差異」是 library 層的隱性 bug 來源。

對應大綱

SQS 進階主題：Standard vs FIFO / Long polling / Client library 維護。

下一步路由

回 SQS vendor 頁 與 3.4 consumer 設計。

引用源

• @lob/sqs-consumer

觀察

Twilio 自己 engineering blog 教使用者用 SQS 緩衝來自 Twilio 的高流量 SMS / status callback webhook（避免下游 app 來不及處理）。用 separate queue 區分 SMS vs status callback、long polling 減少空 API call、特別點出 FIFO 300 TPS 上限要分 queue。

判讀

Webhook 是 push、下游可能來不及、SQS 當 buffer 是常見 pattern。揭露 FIFO 的 300 TPS 上限是 hard limit、要設計分片才能擴張。

對應大綱

SQS 進階主題：Long polling / Standard vs FIFO。

下一步路由

回 SQS vendor 頁 與 3.2 durable queue。

引用源

• Handling High Volume Inbound SMS and Webhooks with Twilio Functions and Amazon SQS

觀察

Rapid7 Platform Software Architect 公開引述：「SQS 是我們架構的關鍵元件、讓我們 scale 到處理 10s of billions of messages per day。」是 AWS 官方文中具名客戶 quote、非 marketing 概括。

判讀

SQS 在百億訊息/日規模下仍可用、是 scale 的具體量級參考點。揭露 SQS request-based 計費在這個規模下、cost 模型該被認真評估。

對應大綱

SQS 進階主題：Cost 模型 / Standard queue。

下一步路由

回 SQS vendor 頁 與 0.6 成本取捨。

引用源

• Amazon SQS — 15 Years and Still Queueing

業務背景

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