Tarragon

"Message-Queue"

• 2026-05-07 3.C1 Meta：FOQS 從區域到全域佇列遷移 佇列架構如何在不中斷下升級成 disaster-ready 模式。
• 2026-04-23 3.1 broker 基礎與投遞模型 先理解 broker、queue、consumer 與 delivery semantics
• 2026-05-07 3.C2 VMware Tanzu CloudHealth：Kafka 轉 Amazon MSK 自管 Kafka 遷移到託管平台時的治理重點。
• 2026-04-23 3.2 durable queue 與重試策略 整理持久化佇列、DLQ 與重試流程
• 2026-05-07 3.C3 LinkedIn：TopicGC 與 Kafka 治理轉換 Kafka topic 從手動治理轉自動治理對叢集的影響。
• 2026-04-23 3.3 outbox pattern 與發佈一致性 把 transaction 與 event publish 分離
• 2026-05-07 3.C4 LinkedIn：Kafka 分層叢集治理 Kafka 從單叢集走向 tiered clusters 的轉換案例。
• 2026-04-23 3.4 consumer 設計與去重 整理 consumer、checkpoint 與 replay safety
• 2026-05-07 3.C5 Slack：Job Queue 演進到 Kafka + Redis 背景工作通道在成長期如何從單一路徑演進成組合式架構。
• 2026-04-24 3.5 攻擊者視角（紅隊）：傳遞層弱點判讀 從重複投遞、重放濫用、毒訊息與容量壓力，盤點 message delivery 的主要弱點
• 2026-05-11 3.6 Processing Semantics 與 Recovery Semantics 說明投遞成功、處理成功與恢復成功為何是三個不同判斷。
• 2026-05-07 3.C6 Uber：Kafka 事件平台演進 事件平台從團隊自管走向多租戶共享基礎設施。
• 2026-05-11 3.7 Event Contract 與 Replay Boundary 說明 event schema、idempotency key、replay window 與補償如何先於 broker 選型。
• 2026-05-07 3.C7 LinkedIn：Kafka 自動修復治理 Kafka 維運從人工處置轉向自動修復的案例。
• 2026-05-11 3.8 Queue Consumer Retry 與 Replay Handoff（實作示範） 以 order_created consumer 示範 queue 路徑如何交付 idempotency evidence、DLQ handling、replay runbook 與 incident decision log。
• 2026-05-07 3.C8 Cloudflare：Queues 全球交付模型 事件佇列服務在全球網路下的交付語義與治理案例。
• 2026-05-07 3.C9 反例：Queue 語義切換誤配 at-least-once / exactly-once 語義誤配導致資料重複與遺漏。
• 2026-05-07 3.C10 對照：規模差異下的佇列模型 同一 queue 模型在不同規模下的治理與失敗邊界差異。
• 2026-06-16 AWS SQS → Google Pub/Sub：queue 模型搬到 topic + subscription 模型的跨雲遷移 SQS 是單一 region-scoped pull queue、Pub/Sub 是 global topic + first-class subscription 的 pub/sub 模型；這篇跨雲 migration playbook 走 6 維 diff dimension audit（components / data topology 軸 High）、對位 visibility timeout → ack deadline、maxReceiveCount → dead-letter topic、long polling → streaming pull、IAM policy → Service Account、SQS-to-many-consumer 要重設計成 topic fan-out；含 5 個 production 故障演練（fan-out 行為差 / ack deadline 太短重投 / ordering key vs FIFO / 跨雲網路成本 / DLT 設定差）跟 dual-publish 漸進 cutover
• 2026-06-16 Google Pub/Sub push vs pull：不是實作偏好，是下游容量的判讀 Pub/Sub 的 push 與 pull subscription 常被當成實作偏好二選一，但它其實是一個容量判讀：push 把流量瞬間打到 endpoint，pull 讓 consumer 自己節流。下游有 RPS 限制就只能 pull。本文展開 subscription 模型、ack deadline、flow control 與 dead-letter topic，5 個把 push/pull 與 ack deadline 寫成下游打爆與重投的 production 踩坑
• 2026-06-16 Kafka Consumer Group Rebalance 與 Lag 診斷：從 protocol 到故障演練 Kafka consumer group 的 rebalance protocol（eager vs cooperative incremental）、static group membership、session.timeout.ms / max.poll.interval.ms / heartbeat.interval.ms 三個 timeout 的職責、consumer lag 均勻分布 vs 集中單一 partition 的診斷路徑、rebalance storm 成因與對策；含 kafka-consumer-groups.sh 實機驗證輸出與 4 個 production 故障演練
• 2026-06-16 NATS core 到 JetStream：fire-and-forget 在哪裡不夠、跨過去要付什麼 Core NATS 的 fire-and-forget 在 consumer 重啟或 rolling deploy 時掉訊息——這不是 bug、是設計。需要訊息不丟就跨進 JetStream（persistence + at-least-once + redelivery）。本文展開 core 與 JetStream 的邊界、stream 與 consumer 的求值模型、實機驗證的 durable pull consumer、5 個把 JetStream consumer 寫成丟訊息與重投風暴的 production 踩坑
• 2026-06-16 Pub/Sub Ordering Key、Dead-Letter Topic 與 Schema Enforcement：三道交付治理 Pub/Sub overview 之下的 implementation-layer deep article — 把 ordering key 的有序代價、dead-letter topic 的 poison message 隔離、schema enforcement 的契約守門三件事寫到可操作：subscription 是 first-class、ackDeadline 與 extension、push vs pull vs streaming pull + flow control、Avro / Protobuf schema、Pub/Sub Lite 與標準版差異、BigQuery / Cloud Storage subscription，含 5 個 production 故障演練（ordering 限流 / ack deadline 太短重投 / DLT max delivery attempts / push 500 retry storm / schema 擋下不相容 publish）
• 2026-06-16 RabbitMQ → Kafka：從『處理即承諾』到『寫入即承諾 + 可 replay』的 paradigm shift RabbitMQ 跟 Kafka 不是同類產品（work queue vs event streaming log）、把 work queue 直接搬成 topic 會踩 paradigm 落差；本文先跑 6 維 diff dimension audit（paradigm 跟 data topology 差最大）、釐清什麼 workload 真該遷什麼不該、再展開 application 重設計的 5 個踩雷（manual ack 觀念帶到 offset commit / routing key → partition key 的 ordering 邊界 / DLX → 自建 DLQ topic / prefetch → max.poll.records / 即刪 vs retention 的 replay 差異）、以及 dual-write / shadow consume 漸進 cutover 與長期混合架構
• 2026-06-16 RabbitMQ DLQ 與分層 retry：別把失敗訊息 requeue 回隊首 RabbitMQ 處理失敗訊息最常見的錯是直接 requeue 回原隊列——它回到隊首、反覆失敗、把後面的訊息全卡住（head-of-line blocking）。正解是用 dead-letter exchange + TTL 組出 work → delay → DLQ 的分層 escalation。本文展開 DLX 求值模型、實機驗證的三層拓樸、5 個把 retry 寫成無限迴圈與隊列阻塞的 production 踩坑，以及 retry 拓樸的容量邊界
• 2026-06-16 Redis Streams → Kafka：從 embedded stream 長成 dedicated event streaming Redis Streams 是 Redis 生態內的 append-only log data structure、Kafka 是專用 distributed event streaming platform；這趟遷移是 paradigm shift — 從 RAM-bound 單 stream key 換成 partition + log retention 的多節點系統。本文先用 Arcjet 反向案例點明多數中小規模 Redis Streams 就夠、不該為流行遷 Kafka、再講真的該遷的訊號（retention 超出 RAM 成本 / 長期 replay / consumer group 規模超出單 Redis）、XADD/XREADGROUP/XACK/MAXLEN/XCLAIM 的對位、retention 成本翻轉與 PEL→offset 誤用的故障演練、漸進 cutover
• 2026-05-19 Kafka ↔ NATS：不是 migration、是 messaging paradigm 重設計 Kafka 跟 NATS 不是同類產品（log-based event streaming vs subject-based messaging）、'migration' 字面上不成立；本文釐清兩家 paradigm 邊界、什麼情境真的能換、application 模式重設計的 5 個踩雷（consumer offset 觀念差 / retention model / exactly-once 假設 / schema registry 缺位 / fan-out 模式差）、跟 JetStream 對位 + 混合架構
• 2026-05-18 3.C11 Pinterest：Kafka tiered storage broker-decoupled Pinterest 採 broker-decoupled tiered storage、把 ~200 TB/day 熱資料卸到 S3、broker 不再是熱路徑。
• 2026-06-22 Kafka → Google Cloud Pub/Sub：從 partition 到 topic-subscription 的模型轉換 從 Apache Kafka 遷移到 Google Cloud Pub/Sub，處理 partition → topic 模型轉換、ordering 語意差異、consumer group → subscription 對應、offset → ack deadline 切換的階段化流程
• 2026-06-16 AWS SQS：Visibility timeout、long polling 與 Lambda event source 的成本與失敗形狀 SQS deep article：visibility timeout 對齊 consumer 處理時間（ChangeMessageVisibility）、long vs short polling 的 cost 取捨（WaitTimeSeconds）、SQS + Lambda event source mapping（batch size / batch window / 並行 ramp-up）、DLQ + redrive policy（maxReceiveCount）、message size 與 extended client、per-request cost 模型；含 5 個 production 故障演練（VT < 處理時間 redelivery、polling 設定省成本、Lambda 部分失敗整批重投、DLQ maxReceiveCount、FIFO 吞吐上限）
• 2026-06-16 Kafka Replication、ISR 與 exactly-once：從 acks 到端到端不重不漏 Kafka 的可靠性由 replication 與 ISR 決定寫入承諾、由 producer idempotence 與 transaction 決定處理語義。本文涵蓋 acks=0/1/all 取捨、min.insync.replicas 與 ISR shrink/expand 的真實行為、enable.idempotence 去重、Kafka transaction + read_committed 隔離、以及端到端 exactly-once 的邊界與成本；含 3-broker 叢集停 broker 觀察 ISR 收縮到低於 min.insync 後 acks=all 被拒的實機演練。
• 2026-06-16 NATS JetStream 設計與 supercluster / leaf node：stream、consumer、跨區拓樸與多租戶 NATS JetStream 的 implementation-layer deep article：stream 設計（storage / retention / discard / 容量上限）、consumer 設計（pull/push、explicit ack、AckWait、MaxDeliver、replay）、Cluster Raft / Supercluster gateway / Leaf node edge 三層拓樸、subject-based ACL 多租戶；含 4 個 production 故障演練（AckWait 太短重投、discard policy 選錯丟訊息、leaf node 斷線重連、stream replica 失去 quorum）。
• 2026-06-16 RabbitMQ → AWS SQS：交出 broker 維運、把 routing 收斂進 application 自管 RabbitMQ 叢集遷到 AWS SQS 是 operational redesign：protocol 不相容、application 要從 manual ack 改成 visibility timeout + delete、exchange routing 收斂成 SNS fan-out 或多 queue；本文跑 6 維 diff dimension audit（operational 差最大）、釐清什麼該遷什麼不該遷、5 個 production 故障演練（DLX → redrive policy / prefetch → batch + visibility / fan-out → SNS-to-SQS / 256KB 大小限制 / ordering 到 FIFO 的吞吐取捨）跟漸進 cutover
• 2026-06-16 Redis Streams XCLAIM / PEL 失敗接管與 Cluster 影響 Redis Streams 把可靠性責任放在 application 層：PEL 記錄已投遞未 ack 的訊息、XCLAIM / XAUTOCLAIM 是 consumer crash 後唯一的接管機制。本文用實機輸出走 PEL / XACK / XCLAIM / XAUTOCLAIM / min-idle-time 機制、5 個故障演練（PEL 卡死、搶單、MAXLEN 修掉未 ack 訊息、Cluster 單 shard 限制、failover 後 PEL 狀態），跟 MAXLEN / XTRIM retention 取捨。
• 2026-05-19 Self-managed Kafka → AWS MSK：把 $15K/month operational cost 拆解到 managed Kafka self-managed → MSK 是 Type C operational redesign — protocol 完全相容、operational stack（ZooKeeper / brokers / monitoring / patching）全託管；本文用 cost 拆解開頭、5 個 production 踩雷（client connection pattern / version pinning / metric pipeline / IAM auth / cross-cluster mirror）
• 2026-05-18 3.C12 Pinterest：Shallow Mirror 優化 MirrorMaker Pinterest 跨 3 region MirrorMaker、原版解壓+重壓造成 CPU/memory 2-10x spike、改 RecordBatch 層淺迭代。
• 2026-06-16 Kafka Retention 與 Tiered Storage：保留策略、log compaction 與冷熱分層 Kafka 的保留策略決定 replay window 與儲存成本：retention.ms / retention.bytes 控制刪除邊界、cleanup.policy 切換 delete 與 compact、log compaction 用最新值取代歷史、tiered storage 把冷資料卸到 S3 讓 broker 容量與保留期解耦。本文涵蓋配置實機驗證、4 個故障演練（replay 失敗 / compaction 不回收磁碟 / cold tier 讀延遲 / retention.bytes 提早刪）、容量成本與整合路由。
• 2026-06-16 RabbitMQ Queue Type 選型：Classic、Quorum、Stream 的責任邊界與容量取捨 RabbitMQ 3.x 三種 queue type 的選型 deep article — classic queue（mirrored 已 deprecated）、quorum queue（Raft 一致性、取代 mirrored）、stream（3.9+ append-only log、可重複消費）。涵蓋三種模型在 throughput / retention / replay / 記憶體成本的判讀、宣告語意差異（實機驗證）、4 個 production 故障演練（mirrored 網路放大 / quorum loss / stream retention 超量 / classic→quorum in-flight message），與容量規劃。
• 2026-05-18 3.C13 Shopify：Debezium CDC over sharded MySQL Shopify 100+ MySQL shard、150 Debezium connector、Black Friday 100K records/sec P99 < 10s。
• 2026-06-16 Kafka Schema Registry 與 schema 演進：wire format、compatibility level 與安全演進規則 Kafka 跨系統事件總線的 schema 治理 implementation deep article — Schema Registry（Confluent / Apicurio）角色、Avro / Protobuf / JSON Schema 取捨、subject naming strategy、backward / forward / full / none 及其 transitive 版本、producer 帶 schema ID 的 5-byte wire format、加欄位帶 default 與刪欄位分步的安全演進規則；含 4 個 production 故障演練與實機驗證的 REST API 回應
• 2026-06-16 RabbitMQ Network Partition 與 Cluster 一致性：腦裂下要保誰 RabbitMQ Erlang cluster 在 network partition 下的行為與處置 — disc/ram node 拓樸、cluster_partition_handling 三策略（ignore / pause_minority / autoheal）的可用性與一致性取捨、腦裂偵測機制、quorum queue 在失去 quorum 時的 Raft 行為。含 3-node OrbStack 實機演練（pause_minority 暫停少數派、quorum queue 失去 quorum 後寫入阻塞、classic queue 同情境續寫對照）。
• 2026-05-18 3.C14 Yelp：Schematizer 自建 Schema Registry Yelp data pipeline 強制所有 message 走 Avro、自建 Schematizer 做 schema evolution 與 topic 自動分配。
• 2026-06-16 Kafka Multi-tenant 治理：quota 限流、ACL 授權與 topic 生命週期 單一 Kafka 叢集承載多團隊時、quota 把頻寬與 request 容量切給每個租戶、ACL 把寫入與讀取權限綁到 principal、topic 命名規範劃出 ownership 邊界、生命週期治理回收死 topic 釋放 metadata 壓力。本文涵蓋 producer_byte_rate / consumer_byte_rate / request_percentage 三類 quota 與 user / client-id / 組合三種套用層級、StandardAuthorizer 的 principal × resource × operation × host 授權模型、prefixed ACL 的 tenant 隔離、TopicGC 式的死 topic 回收、以及四個 production 故障演練（單租戶暴衝吃滿頻寬、ACL 過鬆過緊、topic 數量爆炸壓垮 controller、unused topic 未回收）
• 2026-05-18 3.C15 Airbnb：Spark Streaming Kafka reader rebalance Airbnb logging pipeline 解 partition-task 1:1 造成的 data skew、catch-up 4 小時 lag 要再花 4 小時的反效率。
• 2026-05-18 3.C16 Robinhood：Faust Python stream processing Robinhood 每天 billions of events、Python 團隊不想用 JVM 生態、把 Kafka Streams 移植到 Python。
• 2026-05-18 3.C17 Walmart：Messaging Proxy Service 解 rebalance storm Walmart 每天 trillions of message、25K+ consumer 在 K8s、partition-consumer 1:1 模型撞到擴張極限。
• 2026-05-18 3.C18 Wix：Greyhound TLLSR 解 consumer 卡住 Wix 2000+ microservice 66B msg/day、自建 Greyhound 抽象、TLLSR 框架解 single-partition lag / poison pill / handler 卡住。
• 2026-05-18 3.C19 Wix：Multi-cluster Kafka zero-downtime 遷移 Wix metadata 從 5K topic 漲到 20K topic / 200K partition、controller startup 跟 broker stability 受壓垮、分多 cluster 解決。
• 2026-05-18 3.C20 Spotify：Event Delivery 從 Kafka 遷出（反例） Spotify Kafka 0.7 MirrorMaker best-effort 會掉資料但回報成功、broker restart 後 producer 無法恢復、決定遷到 GCP Pub/Sub。
• 2026-05-18 3.C21 Goldman Sachs：MSK 遷移 with MirrorMaker 2 Goldman Sachs Global Investment Research 從 on-prem Kafka 遷到 MSK、用 MM2 同步 topic/ACL/offset、atomic cutover 7 小時完成。
• 2026-05-18 3.C22 Trivago：KEDA scale-to-zero by Kafka lag Trivago 50+ Kafka sink、CPU/mem autoscaling 無效（I/O bottleneck）、KEDA 以 consumer lag 為訊號達到 scale-to-zero。
• 2026-05-18 3.C23 Bloomberg：多租戶 vhost + 自助平台化 Bloomberg 從幾個團隊推到上百個團隊、靠自助 vhost 註冊跟專用叢集分離應用與 broker。
• 2026-06-22 Retry Policy 說明重試策略如何區分暫時性錯誤、永久錯誤與副作用風險
• 2026-05-18 3.C24 SoundCloud：AMQP fan-out 音訊處理 pipeline SoundCloud 每秒 20-30K persistent message、不同處理類型分開隊列、各自獨立 scale。
• 2026-05-18 3.C25 Indeed：Delay queue + DLQ 三層 escalation Indeed 每天 35M+ 職缺、設計 Requeue → Delay queue → DLQ 三層 escalation 避開 head-of-line blocking。
• 2026-05-18 3.C26 GoCardless：Hutch + 單一 topic exchange service mesh GoCardless 單一 RabbitMQ cluster 作所有 service 通訊中樞、routing key 用 service.subject.action 格式、JSON 多語言可讀。
• 2026-05-18 3.C27 Zalando：RabbitMQ on AWS 自動化 master selection Zalando 用 sidekick 服務查 AWS API 動態識別 cluster、指定最老 instance 當 master、跨版本升級用 federation 過渡。
• 2026-05-18 3.C28 WeWork：Consistent hash exchange 保證帳戶順序 WeWork 固定數量 queue + account ID hash 路由、每 queue 一個 worker + exclusive consumer 保 partition-level ordering。
• 2026-05-18 3.C29 WeWork：Bunny + Puma 多執行緒 channel pool WeWork 從 Unicorn 切到 Puma 後遇 ConnectionClosedError、根因是 AMQP channel 跨執行緒共用、改用 connection_pool 管理。
• 2026-05-18 3.C30 Runtastic：Mirrored queue 網路負載瓶頸 Runtastic 2020 lockdown 流量暴增、performance test 揭露 mirroring 邏輯把網路元件壓垮、調整 mirroring 配置消除瓶頸。
• 2026-05-18 3.C31 Mozilla Pulse：命名前綴 + ACL 取代 vhost 多租戶 Mozilla Pulse 不用 vhost、改用權限 + 命名前綴 (exchange/{user}/*) 做隔離、CloudAMQP 託管、PulseGuardian 管使用者。
• 2026-05-18 3.C32 LoyaltyLion：監控數千 RabbitMQ queue LoyaltyLion 跑數千 queue、用 rabbitmqctl + statsd 推 Datadog、揭露大規模 queue 拓樸下原生 plugin API 不夠用。
• 2026-05-18 3.C33 Wargaming：World of Tanks 戰後 dossier 解耦 Wargaming WoT server 全 Linux、戰後 dossier 寫 RabbitMQ、portal 顯示統計而不增 game server load。
• 2026-05-18 3.C34 Netlify：NATS 當全球 metrics/logs 統一資料平面 Netlify 70K+ 網站、10 億 PV/月、跨多雲、NATS 當 all-purpose data plane fan-out bus、超 RabbitMQ 評估。
• 2026-05-18 3.C35 Form3：NATS JetStream 多雲低延遲支付 Form3 服務 Tier-1 銀行、500ms SLA、SNS/SQS 吃 300ms 預算、改 NATS+JetStream 跨雲 6x 延遲改善。
• 2026-05-18 3.C36 Intelecy：工業 IoT 即時感測 + 多租戶 Intelecy 工廠 gateway 接數萬感測器、< 2 秒往返延遲做即時 ML、從 BoltDB 本地快取演進到 JetStream 持久化。
• 2026-05-18 3.C37 MachineMetrics：邊緣到雲端工廠資料管線 MachineMetrics 跨數百工廠、數千機台、1000Hz 採樣、Kinesis 無法跑在 edge、改 NATS Leaf Node + JetStream + KV + Object Store。
• 2026-05-18 3.C38 Clarifai：NATS Streaming ML 平台非同步任務 Clarifai custom model 訓練、rolling deploy 掉訊息、改 NATS Streaming queue group、3 週遷移 1 服務、5 月 5 服務、每日 100k+ 訊息 100% uptime。
• 2026-05-18 3.C39 Choria：NATS 管 50 萬 server fleet Choria 替代 Puppet MCollective、NATS 單 binary 無 Zookeeper、4GB node 可達 50 萬 server、wildcard + queue group 做 scatter-gather RPC。
• 2026-05-18 3.C40 Resgate：WebSocket-to-NATS realtime API gateway Resgate 把 NATS subject 暴露成 REST + WebSocket、subject 階層當 schema、event 延遲 < 1ms、純 Core NATS。
• 2026-05-18 3.C41 i-flow：NATS 做 OT/IT 跨層整合 bus i-flow 每日 4 億筆 data operation、200+ OT/IT connector、客戶含 Bosch / Sto / Lenze、NATS 當邊緣到 central 整合 bus。
• 2026-05-18 3.C42 Bitso：Reliable Redis Streams 抽象 + 自建 DLQ Bitso 加密交易所、千 msg/sec/stream + 亞毫秒延遲、自建 Reliable Streams 封裝 PEL + retry + DLQ、idempotent processing。
• 2026-05-18 3.C43 Arcjet：Redis Streams 取代 Kafka 省 6 位數 $ Arcjet security 平台、Kafka managed 6 位數 $/yr、用 Redis Streams 約 $1k/yr、自寫 Janitor 監控 retention。
• 2026-05-18 3.C44 Harness：CD 微服務 async state transfer Harness CD 平台用 Redis Streams 解 brittle HTTP、揭露監控缺口 / MAXLEN truncation / head-of-line blocking 三類問題。
• 2026-05-18 3.C45 Klaxit：Rust + Redis Streams 處理 Heroku Logplex Klaxit carpool 用 Redis Streams 處理 Heroku Logplex 匯流、自動偵測修復平台 perf 問題、6 個月 production Rust。
• 2026-05-18 3.C46 Learning.com：Redis 事件源退場（反例） Learning.com 把 microservice event store 放 Redis、1 年累積 GB/週、AOF+EBS 變 latency 痛點、退到 PostgreSQL。
• 2026-05-18 3.C47 PHP 微服務：Redis Streams + S3 hybrid storage PHP 雙微服務通訊、Kafka 在 PHP 生態工具薄弱、用 Redis Streams + payload compression + S3 hybrid 處理大訊息。
• 2026-05-18 3.C48 Airbnb Dynein：SQS 分散式延遲任務排程 Airbnb 用 SQS at-least-once + DLQ 取代 Resque 單 Redis 限制、每 scheduler 1000 QPS、SQS wrap DynamoDB 處理 > 15 分鐘 delay。
• 2026-05-18 3.C49 Airbnb Inspekt：Visibility timeout 當 retry budget Airbnb Inspekt 隱私掃描器、scanner pull message、visibility timeout 自然觸發重現、用重現次數當 retry budget。
• 2026-05-18 3.C50 Capital One：Visibility timeout 設計與 Lambda event source Capital One tech blog 講 SQS + Lambda：visibility timeout 應略高於最大處理時間、Lambda 初 5 個 long polling、可擴 60/min。
• 2026-05-18 3.C51 Atlassian JiRT：Kinesis + SQS subscription Atlassian StreamHub Kinesis 底層、每 consumer 自己一個 SQS queue、JiRT 把輪詢 1 min 改成秒級 event-driven。
• 2026-05-18 3.C52 Nielsen：Spark on EKS 雙 SQS 工作流 Nielsen 每日 25TB / 30B event、work queue + completion queue 雙 SQS、queue depth autoscale EKS pod。
• 2026-05-18 3.C53 FINRA：S3 → SQS notification 大檔上傳 FINRA 金融監管、broker 上傳大檔、S3 → SQS notification → LFS、KMS + bucket policy + queue policy 三層稽核。
• 2026-05-18 3.C54 Twitch EventSub：SNS+SQS fan-out 給第三方 Twitch Event Bus ~1660 events/sec 進 SNS、EventSub 用 SQS 接收 + Dispatcher fan-out 給訂閱者。
• 2026-05-18 3.C55 SmugMug：SQS 驅動可重放搜尋管線 SmugMug 用 SQS 兩種模式：DynamoDB scan-segment 平行 backfill + production query 鏡像 replay 到 replica。
• 2026-05-18 3.C56 PostNL EBE：完整 DLQ + retention + redrive 設計 PostNL 物流每天 1000 萬訊息、每 producer/consumer 隔離 stack、24h 內 100 次 retry、final DLQ 可 consumer redrive。
• 2026-05-18 3.C57 Lob：自家 fork @lob/sqs-consumer 修 FIFO bug Lob 原用 bbc/sqs-consumer 鎖 SDK v2、fork 出 @lob/sqs-consumer 支援 SDK v3 + TypeScript + 修 FIFO bug。
• 2026-05-18 3.C58 Twilio：SQS 緩衝高流量 webhook Twilio 教用 SQS 緩衝 SMS / status callback webhook、分 queue（SMS vs callback）、long polling 減 cost、FIFO 300 TPS 上限要分片。
• 2026-05-18 3.C59 Rapid7：SQS 100 億 message/day 規模 Rapid7 公開引述：SQS 撐 10s of billions of messages per day、是架構關鍵元件、scale 量級的具體參考。
• 2026-05-18 3.C60 Spotify：Event Delivery 從 Kafka 遷到 Pub/Sub Spotify 全球 event delivery 從 Kafka 遷到 Pub/Sub、~2500 VM、Q1 2019 8M events/s、350TB/day raw、自建 dedup。
• 2026-05-18 3.C61 Spotify：Autoscaling Pub/Sub consumer 反效果 Spotify 下游失敗時 consumer 不 ack 仍耗 CPU、autoscaling 越拉越高、解法是 exponential backoff 抑制 CPU。
• 2026-05-18 3.C62 Spotify：Pub/Sub → GCS reliable export Spotify 用 Oldest Unacknowledged Message metric 判斷 hourly bucket 何時可安全關閉、ack 綁定下游 commit。
• 2026-05-18 3.C63 Mercari Actionable History：ack deadline 是 batch-level Merpay 支付流水帳用 Pub/Sub、ack deadline 是整批 batch 而非單訊息、acked 訊息會跟同批 expired 一起 redeliver。
• 2026-05-18 3.C64 Mercari Item Feed：DLT 防 poison message 阻塞 Mercari 商品 feed 同步、ack 整批 / nack 重送、重試多次仍失敗送 DLT、topic 同時當 load-leveling buffer。
• 2026-05-18 3.C65 Mercari LINE：Pull subscription 對齊外部 RPS Mercari LINE webhook 轉 Pub/Sub、worker pull subscription 精確控制 RPS、應 LINE API 限制。
• 2026-05-18 3.C66 Mercari B2C：自建 PubSub gRPC Pusher Mercari 全球商品同步、原生 HTTP push 在「長 job + 高吞吐 + 動態 RPS」場景受限、自建 gRPC 版 push。
• 2026-05-18 3.C67 Niantic Pokémon GO：Pub/Sub 當 telemetry ingest Pokémon GO frontend publish 玩家事件、~1M TPS、Pub/Sub elastic buffer、下游 BigQuery streaming。
• 2026-05-18 3.C68 Wix：Pub/Sub decouple + Dataflow + BQ archive Wix App Engine 收 clickstream 進 Pub/Sub、Dataflow 進 Datastore < 100ms、BigQuery 並行存 raw recovery。
• 2026-05-18 3.C69 Twitter Ad Engagement：把 stream 切成多 topic 做 partition Twitter 把 80K msg/s stream 切成 6 個 topic 做 partition、Avro schema、Beam/Dataflow → Bigtable/BQ。
• 2026-06-22 Consumer Group 說明一組 consumer 如何共同分攤 stream 或 topic 的處理責任
• 2026-06-22 Partition 說明事件流如何切分成多個可並行處理的有序片段
• 2026-06-22 Offset 說明 consumer 在事件流中的讀取位置與重放基準
• 2026-06-22 Queue 說明 queue 如何保存等待處理的工作並形成容量邊界
• 2026-06-22 Consumer 說明 consumer 如何取得等待處理的工作並產生業務結果
• 2026-06-22 Topic 說明 topic 如何把事件依主題分流給不同訂閱者
• 2026-06-22 Fan-out 說明單一事件同時分發給多個下游的訊息拓撲
• 2026-06-16 終端機訊息佇列客戶端：Kafka 的 kaskade/yozefu/ktea 與 Redis 的 iredis 在純文字終端機連 broker、瀏覽 topic、消費訊息、檢視 consumer 狀態的客戶端：Kafka 的全螢幕 TUI（kaskade/yozefu/ktea）、Redis 的增強型 REPL（iredis），以及訊息佇列 TUI 多半綁單一 broker 協議這個跟 SQL 客戶端最大的不同。