Tarragon

"Kafka"

• 2026-06-20 Queue 緩衝 在 ingestion 和 processing 之間加 message queue 做 burst 緩衝 — Kafka / NATS / Redis Streams 的選型和引入條件
• 2026-05-19 CoreWeave 收購 Bufstream：整併週期下的賽道判讀與基礎設施重組 用 WRAP 框架拆解 CoreWeave 買 Bufstream 揭露的串流市場整併、算力廠商對基礎設施的剛需、以及對資料工程師職涯的意涵
• 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 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 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 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-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-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-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-27 MongoDB Change Streams + Kafka 整合：resume token、scope 選擇與 connector 治理 MongoDB change streams 機制（resume token、oplog 容量、cluster-wide vs collection-level scope）跟 Kafka Connector 整合；at-least-once 語義 + idempotency 治理 + resume token 過期防護
• 2026-06-16 終端機訊息佇列客戶端：Kafka 的 kaskade/yozefu/ktea 與 Redis 的 iredis 在純文字終端機連 broker、瀏覽 topic、消費訊息、檢視 consumer 狀態的客戶端：Kafka 的全螢幕 TUI（kaskade/yozefu/ktea）、Redis 的增強型 REPL（iredis），以及訊息佇列 TUI 多半綁單一 broker 協議這個跟 SQL 客戶端最大的不同。