概念位置

四維對照：

典型 LLM 應用的混合：

1User input
2   ↓ Fuzzy（LLM 理解意圖）
3   ↓ Deterministic（DB / API / policy）
4   ↓ Fuzzy（LLM 寫回應）
5   ↓ Deterministic（發送 / 寫入）

設計責任

讀 LLM 應用設計文章或開始設計 production AI 系統時、這個 framing 決定每個 step 的工具選擇。實作判讀：

1. 哪段該 deterministic / 哪段該 fuzzy：規則可窮舉、失敗代價高、需要解釋、需要 byte-exact 重現的 → deterministic；自由文字輸入、生成有風格的輸出、邊界模糊的 → fuzzy。
2. 典範用錯的反模式：deterministic 需求硬用 fuzzy（用 LLM 算稅金）、fuzzy 需求硬用 deterministic（regex 解析自由文字）、邊界混（prompt 內塞算術 / code 內塞意圖分類）。
3. Fuzzy 邊界的四種 guardrail：schema validation、output validator、action gating、distribution monitoring。混用、不同 risk class 分擔不同層。
4. 跟 HITL 的關係：HITL 是 deterministic guardrail 的一種——把人類判斷當 deterministic check 包 fuzzy LLM 行為。
5. 失敗的歸因分層：壞掉時要問「是 prompt / model / context / tool / 還是 deterministic glue 的 bug」。deterministic 軟體歸因單一、fuzzy 軟體要分這幾層查。

完整典範討論見 0.8 Deterministic vs Fuzzy Engineering。

這個位移影響的不只是「在某段程式裡呼叫 LLM」、而是整套設計思維：怎麼處理資料、怎麼定義「正確」、怎麼分解任務、怎麼版本控制、怎麼測試、怎麼除錯。本章把這個典範位移寫成跨應用都成立的心智模型、讓你在後續模組（特別是 模組四 LLM 應用層）讀到 RAG、agent、workflow pattern 時、知道自己在跟哪個典範打交道、該套哪一邊的設計直覺。

本章目標

讀完本章後你能：

1. 區分一段程式碼是 deterministic 還是 fuzzy。
2. 列出兩個典範在四個維度（資料、邏輯、分解、實驗成本）的差異。
3. 判斷一個系統的哪段該 deterministic、哪段該 fuzzy。
4. 設計 fuzzy 邊界的 guardrail（schema / validator / HITL）。
5. 看到一個失敗案例、能定位是「典範用錯」還是「實作問題」。

兩個典範的對照

這張表是後續所有判讀的骨架。看到一段程式時、用這幾個維度自問「這段在哪個典範」、設計直覺自然分開。

為什麼這個位移是典範級、不是只是換工具

很多人把 LLM 當「多了一個 API」、結果是把 LLM 塞進 deterministic 設計框架裡、然後因為它「不夠 deterministic」而 frustrated。這個 framing 錯了。LLM 不是 deterministic 工具的下一代、是另一條工具線、需要另一套設計直覺。

幾個容易踩的混淆：

• 把 LLM 行為當 bug 修：模型輸出不穩定、想用更多 if 把它「夾」回固定行為。這條路會走到死巷——當 prompt 越夾越窄、模型反而開始失去原有能力。正確方向是讓邊界本身可以容忍變化（schema validation + retry、distribution metric、HITL）。
• 用 deterministic 的 test 思維測 LLM：寫了一個「input X 應該得到 output Y」的單元測試、期望 byte-exact match。LLM 行為是分佈、即使 temperature=0、prompt brittleness 也讓單次測試結果不穩。Fuzzy 系統的測試是「在 N 次採樣中、output 落在期望範圍內的比例」、或「分佈級別 metric」、不是「精確等於某 string」。
• 用 deterministic 的 code review 審 LLM-generated code：要求 generated code 完全符合 style guide、結果耗在 nitpick 而不是行為正確性。LLM 生成是 fuzzy 過程、review 焦點該是「功能對 + 安全 + 可讀」、style 交給 linter / formatter 後處理。

典範位移的真正意涵：設計時就承認 fuzziness 存在、並圍繞它設計、不是假裝它不存在。

哪段該 Deterministic、哪段該 Fuzzy

一個系統幾乎不會「全 deterministic」或「全 fuzzy」、實務上是混合。判讀「哪段該哪個」的決策框架：

實務上一個 production LLM 應用的常見組合：

• 使用者輸入解析：偏 fuzzy（LLM 解意圖、parse 自由文字）。
• 資料庫查詢 / 更新：偏 deterministic（SQL、API、schema validation）。
• 業務規則檢查（如「能否退款」「能否變更地址」）：偏 deterministic（policy as code）。
• 回應草稿生成：偏 fuzzy（LLM 寫 email、考慮語氣）。
• 發送 / 寫入動作：偏 deterministic（API call、template render）。

這個混合不是隨機、是按上述決策框架推出來的。LLM 強在「理解模糊輸入」跟「生成有風格的輸出」、其餘部分能 deterministic 就 deterministic。

反模式：典範用錯的訊號

• Deterministic 的需求硬用 fuzzy 解：例如用 LLM 算稅金、然後用 retry + LLM judge 校驗。這條路的成本跟錯誤率都遠高於直接寫 deterministic 規則。判讀訊號：能用 30 行 code 寫死的規則、不要 LLM。
• Fuzzy 的需求硬用 deterministic 解：例如用 regex 解析自由文字客服訊息、然後維護一個越來越長的 case list。判讀訊號：規則 list 每週都在加新 case、加完還是漏、就該換 fuzzy。
• 邊界用錯：把 deterministic 的部分塞進 prompt（如「請計算 9.32 × 47 並退款」）、或把 fuzzy 的部分塞進 code（如 if user_intent == "refund"）。前者讓 LLM 出算術錯、後者讓 code 漏 case。判讀訊號：prompt 在做算術 / 字串解析、或 code 在做意圖分類、就該重切。

Fuzzy 邊界的 Guardrail 設計

承認 fuzziness 存在後、設計重點轉成「邊界要怎麼包」。Guardrail 是 deterministic 包 fuzzy 的設計模式、防止 fuzzy 行為溢出到不該影響的地方。

四種常見 guardrail：

Schema validation

LLM 輸出被強制符合某個 schema（JSON schema、Pydantic model、TypeScript type）。不符合就 retry 或 fallback。

適用：LLM 結果要直接餵給下游 deterministic 系統（API、DB、UI）。

實作位置：LLM call 之後、下游 system 之前。

失敗模式：schema 對了但語意錯（structurally valid、semantically wrong）——這層 guardrail 接不住、要加 semantic check。

Output validator

對 LLM 輸出跑語意驗證、不是只看 schema。例：生成的 email 不能包含未經授權的折扣承諾、生成的 code 不能呼叫 deprecated API。

適用：LLM 輸出有「該做 / 不該做」的清單。

實作位置：LLM call 之後、deliver 之前。可以是 deterministic check（regex、AST 分析）、可以是另一個 LLM judge（見 4.21 LLM-as-Judge）。

失敗模式：validator 自己 hallucinate（如果是 LLM judge）、或漏 case（如果是 deterministic check）。混用兩種比較穩。

Action gating

LLM 想做高代價動作前、強制走人類確認或外部驗證。例：寫 production DB 前要 human approval、發 email 前要 dry-run 給內部 review、執行 shell 前要看到 diff。

適用：副作用範圍大、失敗不可逆。對應 4.4 agent 架構 的 step-by-step approval / HITL 協作模型。

實作位置：tool layer、不是 prompt layer。Prompt 「請小心」是不夠的、靠 tool 本身不執行才有保證。

失敗模式：人類疲勞（rubber-stamp approval）、確認流程變橡皮圖章。設計時要讓 high-risk 跟 low-risk 動作走不同 gate、不要全部要人類確認、否則人類會關掉腦袋。

Distribution monitoring

不在 single call 層擋、而是看 LLM 行為的分佈。例：每天客服回應的「拒絕率」「退款承諾率」、跑 alert；新 prompt 上線後追 token 用量、語氣 polarity、user satisfaction 的 baseline 漂移。

適用：行為層面的 silent drift（個別 call 看不出問題、加總起來偏掉）。

實作位置：production observability、trace pipeline（見 4.20 LLM tracing）。

失敗模式：baseline 沒先建、新 prompt 上線後不知道「正常範圍」是什麼、alert 無基準。

四種 guardrail 怎麼選

順序通常是：schema validation 最便宜先上、output validator 看內容風險再加、action gating 看不可逆性決定、distribution monitoring 是長期經營必備。

混用比例：一個成熟的 production LLM 應用通常四種都有、但分擔不同 risk class。輕量 query 只走 schema、會寫資料的走 schema + validator + gating、會影響多人的走全套加 monitoring。

實驗成本的位移

Deterministic 軟體的實驗成本高、改 code 要 PR review、要跑 CI、要考慮回退、所以團隊文化是「想清楚再寫」。Fuzzy 軟體的實驗成本低——改 prompt 一行、跑兩個 case、就能看新行為——所以更接近「快速試、不行就丟」。

這個位移對工程師的工作方式有實質影響：

• Throw-away code 更可接受：原本「寫了就要維護」、現在「先試、不行就重來」。
• Prompt 是 source、但生命週期不一樣：跟 code 一樣 version control（見 4.10 衍生產物管理）、但 iteration 速度比 code 快一個量級。
• Eval 比 unit test 重要：unit test 鎖行為、但 fuzzy 行為本來就會變、eval 看「行為分佈是否在期望範圍」才是有用的測試。
• 失敗的歸因分層：壞掉時要問「是 prompt 問題、model 問題、context 問題、tool 問題、還是 deterministic glue 的 bug」——deterministic 軟體的歸因比較單一、fuzzy 軟體要分這幾層查。

這個位移是雙面刃。便宜實驗讓 iteration 快、但也讓 prompt / config / 行為快速分裂、production 跑著的東西跟 git 上看到的東西可能不一致。Mitigation 是 prompt template 上 version control、prompt diff 進 CI、production behavior 進 distribution monitoring。

跟 Agent / Workflow 設計的關係

Agent 跟 multi-call workflow 是「fuzzy 軟體」最複雜的型態。4.4 agent 架構 列出 agent 的三大失敗模式（context drift / goal drift / tool misread）、本質上都是 fuzzy 行為在多步累積後溢出 guardrail。

這個 framing 對 agent 設計的啟示：

• Loop 的每一步都是一個 fuzzy 邊界：每步都要決定 schema / validator / gating / monitoring 的組合。
• 越多步累積、越需要 deterministic checkpoint：「跑 10 步 fuzzy 推理、最後一步寫 DB」是高風險、要在中間插 deterministic verification。
• Termination 是 deterministic 邊界：靠模型自己說「完成了」是純 fuzzy、容易失控（見 4.4 termination 條件）。混用 step cap、cost cap、external validation 是 deterministic guardrail 包 fuzzy loop 的標準做法。

何時過時 / 何時不過時

不會過時的部分：

• 兩個典範的四維對照（資料、邏輯、行為一致性、實驗成本）。
• 「哪段該 deterministic / 哪段該 fuzzy」的決策框架。
• 四種 guardrail 的分類跟組合原則。
• Fuzzy 邊界要包 deterministic、不是反過來的設計直覺。

會變的部分：

• 具體 schema 工具（Pydantic、Zod、各家 framework 的 typed output API）。
• 具體 LLM-as-judge 平台跟方法（見 4.21）。
• 各家 framework 的 guardrail SDK（隨工具世代換）。
• Fuzzy / deterministic 的邊界位置會隨模型能力移動——模型越強、能 fuzzy 處理的範圍越大、但「該包 guardrail」的原則不變。

下一章

下一章：模組一 本地 LLM 服務 進入工具層、或跳到 模組四 LLM 應用層 看這個典範怎麼落到 RAG / agent / workflow 設計。Agent 設計怎麼把 fuzzy / deterministic 邊界體現在 loop 結構上見 4.4 agent 架構、人類介入點的設計選擇見 4.5 人機協作拓樸、跨多 call workflow 的 fuzzy 邊界設計見 4.7 workflow 編排模式。

本文是跨 vendor migration playbook、cross-link 到 RabbitMQ 跟 Kafka。跟同類產品的 drop-in 或 operational 遷移不同、本篇是 paradigm shift — 兩端不是「同類 broker 的不同實作」、是 不同責任模型的 messaging system：RabbitMQ 是「處理即承諾」的 work queue、Kafka 是「寫入即承諾、可長期 replay」的 event log。

RabbitMQ → Kafka 不是把 queue 換成 topic

RabbitMQ 跟 Kafka 都被歸在「message queue」這個傘狀詞下、但兩者承擔的責任不同。RabbitMQ 的可靠性建立在 consumer 處理完才 ack、未 ack 的訊息 broker 重新投遞；訊息一旦被成功消費就從 queue 移除、broker 是「任務分派 + 重試」的中介。Kafka 的可靠性建立在 訊息寫進 partition log 就持久化、consumer 各自維護 offset；訊息在 retention 期內一直留著、broker 是「事件儲存 + 多方各自讀取」的 log。

把 RabbitMQ「migration」成 Kafka 的字面理解通常是：queue 對 topic、exchange 對 producer key、consumer 對 consumer group。這個對映在 transport 層成立、在責任層不成立。RabbitMQ 一個 message 被 ack 後就消失、Kafka 一個 message 寫進 log 後對所有 consumer group 都還在；RabbitMQ 的 routing 由 broker 端 exchange + binding 決定、Kafka 的「routing」由 producer 端 partition key 決定、broker 不做內容路由。先確認這層差異、再決定哪些 workload 值得遷。

6 維 diff dimension audit

跨 vendor 遷移前先盤點 source 跟 target 在六個維度的落差、用最大落差維度決定 playbook 結構、而不是反過來套既有模板。RabbitMQ → Kafka 的 audit 結果：

三個維度 High：paradigm、application change、data topology。其中 paradigm 是主導維度 —— application change 跟 data topology 的落差都是 paradigm 落差的下游結果。consumer 要重寫，是因為「ack 後即刪」變成「offset 不刪」；資料拓樸要重劃，是因為「broker 路由到 queue」變成「producer 決定 partition」。

主導維度是 paradigm、對映 Type E paradigm shift 結構：先講「字面 migration 不成立」、再講適配度（什麼能遷什麼不能）、再講 application 重設計與部分 cutover、最後是長期混合架構。application change 跟 data topology 這兩個高維度不另起 playbook、而是落在 application 重設計段與故障演練段裡展開。

為什麼 paradigm 是主導、不是 application change

application change 看起來工作量最大（consumer / producer 都要改），直覺會把它當主導維度。但 application change 的方向跟難度是由 paradigm 決定的：如果只是 AMQP client 換 Kafka client、心智模型不變，那 application change 是機械式翻譯、屬於 Schema/API 維度。實際上 consumer 不只是換 SDK、是要把「處理完才 ack、失敗就 nack 重投」的設計改成「拉一批、處理、commit offset、失敗自己重試或寫 DLQ topic」—— 這是責任模型的改變，不是 API 的改變。所以主結構走 paradigm、application change 是它的展開。

什麼 workload 真該遷、什麼不該

判讀的核心問題是：這個 workload 需要的是「處理一次就完成的任務」、還是「被多方各自讀取、可回放的事件」。

任務分派場景不該遷。寄信、轉檔、生成縮圖這類 workload 的本質是「有一個工人池、把任務做完就結束」、RabbitMQ 的 manual ack + prefetch + DLX 對這條路徑是貼合的設計。把它搬到 Kafka 會引入不需要的複雜度：partition 數要規劃、consumer group rebalance 要管、offset commit 時機要自己設計、而換來的 replay 能力在「任務做完就丟」的場景根本用不到。單純 work queue 不需要 Kafka 是這篇 playbook 最該先說清楚的判讀。

事件流場景該遷。當同一份事件要被 analytics pipeline、search index sync、audit log、下游微服務各自消費、而且各自進度不同、偶爾要回放過去 N 天重算 —— RabbitMQ 的「ack 後即刪」就會逼出「為每個 consumer 複製一份 queue」的反模式，這正是 Kafka 的 consumer group + retention 要解的問題。

複雜 routing 場景要重新設計、不是平移。RabbitMQ 的 topic exchange 用 order.*.created 這種 binding pattern 在 broker 端做內容路由、consumer 訂閱 binding 就收到符合的訊息。Kafka broker 不做內容路由，要嘛把路由邏輯前移到 producer（按內容決定寫哪個 topic / partition key），要嘛 consumer 端全收後自己 filter。直接平移會發現 Kafka 沒有 exchange 這個概念，routing 拓樸必須重新設計。

為什麼會考慮這個 paradigm shift

實務上從 RabbitMQ 評估遷往 Kafka 通常由三條 driver 觸發：

1. 同一事件要 fan-out 給愈來愈多 consumer：初期一個 queue 一個 worker、後來下游團隊一個個來要「也給我一份」。RabbitMQ 要嘛加 fanout exchange + 每團隊一個 queue、要嘛 consumer 互搶。Kafka 的 consumer group 天然支援「N 個獨立團隊各自從頭讀」、這是最常見的 driver。
2. 需要 replay 重算：下游邏輯出 bug、要重跑過去 7 天的事件修資料；RabbitMQ ack 後訊息已刪、無從回放。Kafka retention 期內可以從任意 offset 重讀。
3. 吞吐量壓到 RabbitMQ 的設計邊界：單 queue 的 throughput 受限於單一 queue 的處理模型、量大時要拆 queue 手動分流；Kafka 的 partition 並行是 first-class。

這三條 driver 都指向 event streaming 的特性、不是「Kafka 普遍比較好」。任務隊列場景套不上這三條 driver、就不該被這個評估帶著走。

Migration 結構：application 重設計 + 部分 cutover + 長期混合

RabbitMQ → Kafka 不是一次性 cutover，是按 workload 拆分、漸進遷移、長期共存：

1. Phase 0：workload 盤點 — 把現有 queue / exchange 逐一分類「適合 Kafka（event 性質）」vs「保留 RabbitMQ（task 性質）」。盤點輸出是清單，不是「全遷」。
2. Phase 1：application code 重設計 — 對判定要遷的 workload，重寫 producer（exchange routing → topic + partition key）跟 consumer（manual ack → offset commit + 自管重試 / DLQ）。這是 paradigm 翻譯，不是 SDK 替換。
3. Phase 2：dual-write 並行 — producer 同時寫 RabbitMQ 跟 Kafka、新 consumer 從 Kafka shadow consume 驗證行為對齊、舊 consumer 持續從 RabbitMQ 消費。
4. Phase 3：cutover 個別 workload — shadow 驗證通過後、把該 workload 的真正消費切到 Kafka、停掉 RabbitMQ 端的對應 consumer 與 dual-write。
5. Phase 4：長期混合 — task 性質的 workload 永遠留在 RabbitMQ、event 性質的在 Kafka。兩者共存是終態、不是過渡。

整體不是「把 RabbitMQ 換成 Kafka」、是「把適合 event log 的部分搬到 Kafka、其餘留在 RabbitMQ」。多數環境的終態是兩者並存。

Application 重設計範例：manual ack → offset commit

RabbitMQ consumer 的核心是 每個 message 處理完顯式 ack、broker 才認定投遞成功；失敗就 nack、broker 重投或進 DLX。Kafka consumer 沒有 per-message ack 的概念、是 批次拉取、處理、commit offset；commit 的是「讀到哪了」、不是「哪幾條成功了」。

 1# RabbitMQ 端：manual ack、per-message 成敗
 2channel.basic_qos(prefetch_count=10)
 3
 4def on_message(ch, method, properties, body):
 5    try:
 6        process(body)
 7        ch.basic_ack(delivery_tag=method.delivery_tag)
 8    except Exception:
 9        # 拒絕並不重新入列、由 DLX 接住
10        ch.basic_nack(delivery_tag=method.delivery_tag, requeue=False)
11
12channel.basic_consume(queue="orders", on_message_callback=on_message)
13channel.start_consuming()

 1# Kafka 端：批次 poll、處理後 commit offset
 2consumer = KafkaConsumer(
 3    "orders",
 4    group_id="orders-worker",
 5    enable_auto_commit=False,        # 關掉 auto commit、自己控制時機
 6    auto_offset_reset="earliest",
 7    max_poll_records=10,             # 對應 RabbitMQ 的 prefetch
 8)
 9
10for batch in iter_batches(consumer):
11    for msg in batch:
12        try:
13            process(msg.value)
14        except Exception:
15            send_to_dlq_topic(msg)   # 自建 DLQ topic、Kafka broker 不提供 DLX
16    consumer.commit()                # commit 的是 offset、不是個別 message

差異的關鍵不在 API 形狀、在責任邊界：

• RabbitMQ 一條失敗就 nack 一條、其餘正常 ack；Kafka commit 的是 offset 這個「水位線」、水位線以下視為已處理。失敗的單條訊息無法「跳過不 commit 但繼續往後」—— 要嘛阻塞、要嘛自己寫 DLQ topic 後讓 offset 照常前進。
• RabbitMQ 重試由 broker 負責（重投 / DLX）；Kafka 重試要 application 自己設計（原地重試 / 寫 retry topic / 寫 DLQ topic）。
• RabbitMQ prefetch 控制「broker 一次推幾條未 ack 的給我」；Kafka max.poll.records 控制「我一次 poll 拉幾條」—— 方向相反，一個是 broker push、一個是 consumer pull。

Production 故障演練

Case 1：manual ack 觀念帶到 offset commit、誤判「已處理」

徵兆：cutover 後某 worker crash 重啟、發現一批訊息被重複處理；或反過來、一批訊息明明沒處理成功卻再也讀不到。RabbitMQ 端跑了多年的 ack 邏輯搬過來就出事。

根因：把 RabbitMQ 的「per-message ack」心智直接套到 Kafka 的 offset commit。常見錯法是 enable.auto.commit=true + 預設 auto.commit.interval.ms、消費迴圈還沒處理完、背景 thread 已經把 offset commit 出去了 —— crash 後 offset 已前進、未處理的訊息永遠跳過（資料遺失）。或反過來、處理完才 commit 但 commit 失敗、重啟後從舊 offset 重讀（重複處理）。RabbitMQ 的 ack 是「這一條我處理完了」、Kafka 的 commit 是「這個 offset 之前我都讀過了」—— 後者是水位線、不是逐條確認。

修法：

1. 關掉 auto commit、手動 commit：enable.auto.commit=false、在一批訊息確實處理完之後才 commit()。
2. 接受 at-least-once、設計 idempotency：Kafka 的預設語意是 at-least-once、重啟重讀無法完全避免、consumer 端要用 message key + dedup store 顯式去重。對應 6.12 idempotency / replay。
3. commit 時機對齊處理邊界：批次處理完才 commit、不要一邊處理一邊讓背景 commit 跑在前面。

Case 2：routing key → partition key、ordering 邊界悄悄改變

徵兆：cutover 後同一個訂單的 created / paid / shipped 事件偶爾亂序到達 consumer；RabbitMQ 端用 consistent hash exchange 跑了兩年、同一訂單的事件一直是有序的。

根因：RabbitMQ 用 consistent hash exchange 把同 key 的訊息路由到同一個 queue、單一 consumer 順序處理就有序。Kafka 的 ordering 保證範圍是 單一 partition 內、跨 partition 無序。如果 producer 沒設 partition key、或設了但 key 選得不對（例如用 event type 當 key 而不是 order id）、同一訂單的事件就散到不同 partition、被不同 consumer 並行處理、ordering 就斷了。RabbitMQ 的 ordering 邊界是「queue」、Kafka 的 ordering 邊界是「partition key」—— 邊界從 broker 端的 binding 移到了 producer 端的 key 選擇。

修法：

1. ordering 單位當 partition key：需要保序的單位（order id / user id）設成 partition key、同 key 落同 partition。
2. 盤點現有 RabbitMQ 的保序假設：哪些 queue 隱含「同 key 有序」、把那個 key 顯式提升為 Kafka partition key。
3. 接受 partition 數限制並行：保序的代價是同 key 只能單一 partition、partition 數是並行上限；保序需求跟並行度需要一起設計。對應 Partition 卡。

Case 3：DLX → 自建 DLQ topic、毒訊息卡住整個 partition

徵兆：某條訊息 application 處理永遠拋例外、consumer 不斷在這條上重試、整個 partition 後面的訊息全卡住、consumer lag 暴增；RabbitMQ 端這種毒訊息會被 nack 進 DLX、不影響後面。

根因：RabbitMQ 有原生 DLX、處理失敗的訊息 nack 後自動進 dead-letter exchange、queue 繼續往下。Kafka broker 沒有 DLX 概念、也沒有「跳過這一條」的機制 —— offset 是連續水位線、要往後就得處理掉當前這條。如果 application 在毒訊息上無限重試、offset 永遠不前進、後面所有訊息餓死。把 RabbitMQ「broker 幫我處理毒訊息」的假設帶過來、就會卡死。

修法：

1. 自建 DLQ topic：consumer 端設重試上限、超過上限把訊息寫進專屬的 orders.DLQ topic、然後 commit offset 讓主流程前進。對應 Dead-letter queue 卡。
2. retry topic 分層：仿 RabbitMQ 的延遲重試、可以設 orders.retry.5s / orders.retry.1m 多層 retry topic、由獨立 consumer 延遲後重投主 topic。
3. DLQ 要有人看：自建 DLQ topic 不像 RabbitMQ management UI 有現成可視化、要主動監控 DLQ topic 的訊息數、否則毒訊息靜默堆積。

Case 4：prefetch → max.poll.records，poll 間隔超時觸發 rebalance

徵兆：consumer 處理一批訊息花的時間偏長、Kafka 突然判定這個 consumer 死了、觸發 rebalance、partition 被重新分配、同一批訊息被另一個 consumer 重複處理；RabbitMQ 端用 prefetch 控制併發從沒這問題。

根因：RabbitMQ prefetch 只控制「broker 一次最多推幾條未 ack 給這個 consumer」、處理多久 broker 不管。Kafka 用 max.poll.interval.ms 監控「兩次 poll 之間最多隔多久」、如果一批 max.poll.records 拉太多、處理超過 max.poll.interval.ms 還沒回來 poll、broker 認定 consumer 卡死、踢出 group 觸發 rebalance。把 prefetch 的數值直接套成 max.poll.records、又沒考慮單批處理時間、就會超時。

修法：

1. max.poll.records 配合單條處理時間設：一批的總處理時間要明顯小於 max.poll.interval.ms；處理慢就把 batch 設小。
2. 長處理 workload 調大 max.poll.interval.ms：單條本來就慢（呼叫外部 API）的、把 interval 放寬、或把處理移到另一個 thread pool、poll 迴圈只負責拉取。
3. 理解 push vs pull 的差異：RabbitMQ 是 broker push、consumer 慢只是堆積；Kafka 是 consumer pull、consumer 慢會被誤判為死亡。這層差異是 prefetch 跟 max.poll.records 不能直接對映的根因。對應 Consumer group 卡。

Case 5：RabbitMQ 即刪 vs Kafka retention、replay 行為差異炸出資料量

徵兆：團隊以為 Kafka「跟 RabbitMQ 一樣處理完就沒了」、結果 disk 持續長大；或反過來、需要 replay 時才發現 retention 設太短、要回放的事件已經被清掉。RabbitMQ 心智下「訊息消費完就不佔空間」的假設不成立。

根因：RabbitMQ ack 後訊息即刪、queue 的空間隨消費釋放。Kafka 寫進 log 後在 retention 期內一直留著、不管有沒有被消費 —— 這正是 replay 能力的來源、也是 disk 成本的來源。沒設好 retention，要嘛留太久 disk 爆、要嘛留太短該 replay 時沒得 replay。RabbitMQ 沒有「retention」這個旋鈕（它是 ack 即刪），Kafka 必須顯式設 retention policy。

修法：

1. 按 replay 需求設 retention：event sourcing 要回放幾天就設幾天的 retention.ms、不是抄 RabbitMQ 的「處理完即刪」心智。
2. 算清 retention 的 disk 成本：retention × 寫入速率 = 佔用空間、納入容量規劃；對比 RabbitMQ 只佔「未消費」的量、Kafka 佔「retention 期內全部」的量。
3. compact topic 給狀態類資料：如果只需要「每個 key 最新值」（像 RabbitMQ 不存在的場景）、用 cleanup.policy=compact 而非 time-based delete、避免無限長大。對應 Topic 卡的 retention policy。

漸進 cutover：dual-write 與 shadow consume

paradigm shift 不能一次切換、因為 consumer 行為（offset 語意、ordering、DLQ、重試）全變了、需要在真實流量下驗證新 consumer 跟舊 consumer 結果一致才敢切。漸進 cutover 用兩個機制：

dual-write：producer 同時往 RabbitMQ 跟 Kafka 寫同一份事件。RabbitMQ 端維持舊 consumer 正常生產、Kafka 端讓新 consumer 接收。dual-write 期間 RabbitMQ 仍是 source of truth、Kafka 只是並行驗證。要處理的細節是雙寫的一致性 —— 寫了 RabbitMQ 但 Kafka 寫失敗時怎麼辦、實務上通常容忍 Kafka 端短期缺漏（因為還沒切過去）、但要監控雙端的訊息數落差。

shadow consume：新的 Kafka consumer 跑完整處理邏輯、但 side effect 導到影子環境（寫影子 DB、不發真實 webhook、不寄真實信）。把 Kafka consumer 的處理結果跟 RabbitMQ consumer 的真實結果比對、確認 ordering、去重、DLQ 行為都對齊。shadow 期是 paradigm 翻譯正確性的驗證窗口、不是效能測試。

cutover 是 per-workload 的：某個 workload shadow 驗證通過、就把它的真實消費切到 Kafka、停掉該 workload 的 RabbitMQ consumer 與 dual-write；其他 workload 維持原狀繼續驗證。不是全站一次切。

Capacity / cost 對照

判讀：純 work queue 場景 RabbitMQ 的運維成本顯著低、Kafka 的 storage 跟運維是為了 replay 與高吞吐付的價。如果 workload 用不到 replay 跟跨 consumer group fan-out、遷到 Kafka 是用更高的成本換用不到的能力。

整合 / 下一步

混合架構是 long-term default

多數環境的終態是 RabbitMQ 與 Kafka 共存、各管各的責任：

1[task 分派：寄信 / 轉檔 / webhook]        [event log：CDC / 事件總線 / replay]
2         RabbitMQ                                    Kafka
3         │                                            │
4         └──────── Bridge（Connect source / 自寫）────┘

RabbitMQ 跑「處理即承諾」的任務隊列、Kafka 跑「寫入即承諾」的事件流。需要從任務流產生事件記錄時、用 Kafka Connect 的 RabbitMQ source connector 或自寫 bridge 把選定的訊息搬到 Kafka topic。

跟 outbox pattern 對位

從 RabbitMQ 遷往 Kafka 常伴隨 資料庫交易與事件發布一致性 的需求 —— 因為 event sourcing 場景要求事件不能丟。直接在交易中寫 Kafka 有雙寫一致性問題、應該走 3.3 outbox pattern：交易內只寫 outbox 表、再由 Debezium CDC 把 outbox 變更發到 Kafka topic。

跟其他 migration 結構的對照

兩篇都是 paradigm shift、都是 partial migration + 長期混合。差別在落差的方向：Kafka ↔ NATS 是 log vs subject messaging 的抽象層差異、RabbitMQ → Kafka 是 work queue vs event log 的責任模型差異 —— 後者的核心翻譯是「處理即承諾」如何重新表達成「寫入即承諾 + offset replay」。

相關連結

• Source / target vendor：RabbitMQ / Kafka
• 平行 vendor：NATS / Redis Streams
• 平行 migration playbook：Kafka ↔ NATS / Kafka → MSK
• 關鍵概念卡：Partition / Topic / Consumer group / Dead-letter queue / Ack/nack
• 下游能力：3.3 outbox pattern / 3.4 consumer 設計 / 6.12 idempotency / replay
• Methodology：Migration Playbook 寫作方法論

本文是跨 vendor migration playbook、cross-link 到 Redis Streams 跟 Kafka。對位 Kafka ↔ NATS 的 paradigm shift 模板 — 兩端不是同類產品的不同實作、是不同抽象層的系統：一個是 Redis 行程內的 append-only log data structure、一個是專用的 distributed event streaming platform。

Redis Streams 跟 Kafka 是不同抽象層的東西

Redis Streams 是 Redis 行程內的一個 data structure、Kafka 是一整套獨立的 distributed event streaming platform。這個區別決定整趟遷移的性質：要把 messaging 能力從「既有 Redis 行程的一塊記憶體」搬到「自成一格、要獨立運維的多節點叢集」，遠超過換個相容 broker 的工作量。

Redis Streams 的責任邊界是「在已經跑著的 Redis 裡多一個 append-only log」。它共用 Redis 的記憶體、持久化（AOF / RDB）、failover（Sentinel / Cluster）跟運維團隊。寫入用 XADD、消費用 XREADGROUP，consumer group 跟 pending entries list（PEL）都活在同一個 Redis 行程。它的設計取捨偏向「低延遲、低運維增量、跟 Redis 生命週期綁定」。

Kafka 的責任邊界是「成為跨系統的事件總線」。它把訊息寫成 partition 化的 log、落在獨立 broker 的磁碟、用 replication 保護、用 consumer group offset 追蹤各 consumer 進度，可長期保留並隨意 replay。它的設計取捨偏向「寫入即承諾、磁碟級長期保留、多 consumer 各自重播、水平擴展吞吐」。

關鍵在「拓樸單位」這列。Redis Streams 的一個 stream key 只能落在單一 shard、沒有 partition 概念，吞吐與資料量受單 shard 的記憶體與單執行緒處理能力封頂。Kafka 的 topic 天然切成多 partition、分散到多 broker，這是兩者在規模上的分水嶺，也是後面所有對位與故障演練的根。

先確認是不是真的該遷：多數中小規模不該遷

決定遷移前先做反向確認：在中小規模、且團隊已熟 Redis 的情境，Redis Streams 往往已經夠用，把它換成 Kafka 多半是引入運維負擔而非解決問題。遷移的正當理由來自規模或保留需求真的超出 Redis Streams 的能力邊界，而不是 Kafka 更主流。

Arcjet 的方向恰好相反、值得當反向參照。Arcjet 的 security / bot detection 平台需要低延遲請求處理，原本評估 Kafka，發現 managed Kafka 要六位數美元年費、自管運維難度也高；他們把既有的 Redis cache 層升級成 Streams，總成本掉到約一千美元年費。代價是 Redis Streams 沒有自動 retention，他們自寫一個 Janitor process，依約每分鐘一百則的實際處理速度監測 stream 長度跟 consumer group 狀態、selectively trim。

Arcjet 的判讀對遷移方向的啟示：當 workload 是低延遲、資料量留在記憶體可承受的範圍、團隊本來就在跑 Redis，Redis Streams 是務實且便宜的選擇；願意自寫 retention 工具就能補上它缺的治理能力。這條路成立時，遷去 Kafka 是用六位數年費跟一整套叢集運維，去換一個現有方案已能覆蓋的需求。

Bitso 是另一個 Redis Streams 站得住的高壓案例。Bitso 的撮合引擎微服務要扛每秒上千則訊息、亞毫秒延遲、撐住 BTC 價格暴動的尖峰；他們先後評估 Kafka（延遲不符）跟 SQS（vendor lock-in + 延遲）後選 Redis Streams，自建一層 Reliable Streams 抽象封裝 PEL + retry + DLQ，走 idempotent processing 接受重複勝過遺失。Bitso 揭露 Redis Streams 是「資料結構」而非「broker 系統」，可靠性責任在 application 層；但在亞毫秒延遲是硬指標的撮合場景，這個取捨反而讓 Redis Streams 勝過 Kafka。

兩個案例共同點：當延遲是硬指標、資料量在 RAM 可承受範圍、團隊能自建缺的治理層，Redis Streams 就站得住。遷去 Kafka 的決策該建立在這些前提不再成立之上，而不是建立在 Kafka 更有名之上。

真正該遷的訊號

決定遷移的依據是 Redis Streams 的三個能力邊界被實際 workload 突破：retention 需求超出 RAM 的成本曲線、需要長期 replay、consumer group 或 partition 規模超出單一 Redis 行程。三個訊號中任一個被觸發、且自建工具補不回來時，遷去 Kafka 才划算。

第一個訊號是 retention 超出 RAM 的成本翻轉。Redis Streams 的資料活在記憶體，保留越久、stream 越長、佔的 RAM 越多，而 RAM 是 Redis 叢集裡最貴的資源。當 retention 需求從「幾小時的緩衝」長到「數天到數週的事件保留」，把這些資料留在 RAM 的成本會快速超過 Kafka 把同樣資料留在 broker 磁碟（甚至 tiered storage 到 S3）的成本。Learning.com 退場案例就是這條線被突破的反例 — 把 Redis 當長期事件儲存（Stream 是其中一塊），事件量每週以 GB 成長、AOF fsync 與 EBS I/O 變成 latency 痛點，最終退回 PostgreSQL。成本曲線翻轉是最常見、也最該觸發遷移的訊號。

第二個訊號是需要長期 replay。事件溯源（event sourcing）或合規稽核場景，需要保留並重播數週、數月甚至數年的歷史事件。Redis Streams 的 replay 只能重讀 retention 內還在的資料，而 retention 受 RAM 限制無法拉得很長；Kafka 的磁碟保留加 tiered storage 讓長期 replay 變成 first-class 能力。當 replay 視窗的需求超出 RAM 能承受的 retention，這個訊號成立。

第三個訊號是 consumer group 或 partition 規模超出單一 Redis。Redis Streams 的單一 stream key 綁在單一 shard，吞吐受單 shard 封頂、沒有 partition 可以水平拆分並行度；要跨 shard 只能手動用 hash tag 切成多個獨立 stream，application 自己路由。當單一邏輯 stream 的吞吐需求、或 consumer 並行度需求超過單 shard 能給的，且手動切 stream 的複雜度已經失控，Kafka 的原生 partition 才值得換。

這三個訊號之外，還有一個放大條件：是否需要 Kafka 生態（Schema Registry、Connect / Debezium CDC、Streams 流處理）。如果遷移同時要接上 CDC pipeline 或 schema 強制治理，那 Kafka 帶來的不只是 retention 跟 partition、而是整套生態，這會讓遷移的價值天平更傾向 Kafka。但若只是想要更長 retention、生態用不到，先評估 Redis tiered 方案或自建 Janitor 是否更便宜。

概念對位：XADD/XREADGROUP/XACK/MAXLEN/XCLAIM

遷移的核心工作是把 Redis Streams 的五個核心操作對應到 Kafka 的等價概念、並理解每個對位背後語意的偏移，這比換 SDK 重得多。直接照字面搬會在 retention、消費進度、失敗接管三處踩雷，這三處正是後面故障演練的來源。

XADD 對 producer.send 的最大偏移是 partition key。Redis 的單一 stream key 沒有 partition，所有 entry 都在同一條序列上嚴格有序；Kafka 把訊息依 key 雜湊分到不同 partition，只有同一 partition 內保證有序。遷移時要決定哪個欄位當 partition key、這個決定同時決定了 ordering 的範圍跟 hot partition 的風險。

XREADGROUP 對 consumer group 的偏移在 rebalance。Redis consumer group 沒有自動 rebalance，consumer 掛掉後它名下未 ack 的訊息留在 PEL，要靠其他 consumer 主動 XCLAIM 接管；Kafka 的 consumer group 有 rebalance protocol，consumer 加入或離開時 broker 自動把 partition 重新分配。從手動接管搬到自動 rebalance，application 端負責接管的那段邏輯可以刪掉、但要改成理解 rebalance 行為。

XACK 對 offset commit 是最容易誤用的一處，獨立成下一節的故障演練。MAXLEN 對 retention policy 是成本模型翻轉的核心，也獨立成故障演練。

Production 故障演練

Case 1：Retention 模型從 RAM 限制翻成 log 成本，磁碟與成本失準

徵兆：團隊把 Redis Streams 的 MAXLEN 100000（保留最近十萬則、控制 RAM）習慣直接對映成 Kafka 的某個數字，結果 cutover 後不是 broker 磁碟暴漲超出預期、就是資料保留遠短於業務需要、replay 視窗對不上。

根因：Redis Streams 的 MAXLEN 是 application 在每次 XADD 主動修剪的「條數上限」，目的是壓住 RAM 佔用，是一個 count-based 的記憶體預算旋鈕。Kafka 的 retention 是 broker 端被動執行的 policy、預設是 time-based（retention.ms）或 size-based（retention.bytes），目的是控制磁碟保留窗，而磁碟比 RAM 便宜一到兩個數量級。兩者的單位、執行主體、成本曲線都不同 — 把「保留十萬則以省 RAM」直接搬成 Kafka 設定，會錯估磁碟用量，也會把 Redis 時代「為了省 RAM 而被迫短保留」的限制錯誤地帶進一個本來就能長保留的系統。

修法：

1. 從業務需求重算 retention、不沿用 Redis 的 RAM 預算：Redis 的 MAXLEN 數字是 RAM 成本的妥協、不是業務的真實保留需求；遷移時回到「業務需要 replay 多久」重新算 retention.ms，這正是遷移要解鎖的能力。
2. 改用 time-based 為主、size-based 當保險絲：Kafka 設 retention.ms 對齊業務 replay 窗、再設 retention.bytes 防單 partition 磁碟失控。
3. 長保留接 tiered storage：retention 需求拉到數週數月時，把冷資料分層到 S3、熱資料留本地磁碟，成本曲線進一步壓平，而這在 Redis 的 RAM 模型下做不到。

Case 2：PEL 觀念被帶進 offset，造成重複或漏消費

徵兆：遷移後 consumer 出現「明明處理過的訊息又被重新消費」或「某些訊息整批沒被處理」；團隊照 Redis 時代「逐則 XACK」的心智模型管理 Kafka offset commit，結果對不上。

根因：PEL 跟 offset 是兩個不同的進度模型。Redis Streams 的 PEL 是 broker 維護的「逐則待 ack 集合」，每則訊息獨立追蹤是否已 ack，consumer 可以亂序 ack 某幾則、其他留在 PEL；XACK 是針對特定 entry ID 的點狀確認。Kafka 的 offset 是 per partition 的單調位移、代表「這個位置之前都算消費完」，commit offset N 意味著 0 到 N-1 全部視為已處理。把 PEL 的逐則語意套到 offset 上會出兩種錯：一是處理完亂序的訊息後 commit 了較大的 offset，中間沒處理完的訊息被當成已消費而漏掉；二是 commit 時機錯置（auto-commit 在處理前就 commit），crash 後從錯誤位置重讀造成重複。

修法：

1. 理解 offset 是區間承諾、不是逐則確認：commit offset 前確保該 offset 之前的訊息都已處理完、不要對亂序處理的批次 commit 最大 offset。
2. 關 auto-commit、改 manual commit 在處理之後：enable.auto.commit=false，處理完一批再 commit，對齊 at-least-once。
3. 保留 application 端 idempotency：這點從 Redis 時代就該有、遷到 Kafka 仍成立 — at-least-once 下重複難免，用 message ID + dedup store 顯式去重，對位 idempotency 卡跟 Bitso 的 idempotent processing。

Case 3：單 stream key 換成多 partition，ordering 假設破裂

徵兆：遷移前所有事件在單一 Redis stream 上嚴格有序、downstream 依賴這個順序（例如同一筆訂單的 created → paid → shipped）；切到 Kafka 多 partition 後，同一筆訂單的事件被分到不同 partition、處理順序錯亂。

根因：Redis Streams 的單一 stream key 綁單一 shard、所有 entry 在一條序列上全域有序，application 不需要思考 ordering 範圍就免費得到全序。Kafka 把 topic 切成多 partition 來換取水平吞吐，代價是只保證 同一 partition 內 有序、partition 之間無序。遷移時若沒指定 partition key、訊息會被 round-robin 或依預設雜湊散開，同一個業務實體（訂單、帳戶、裝置）的事件落到不同 partition，全序假設就破了。

修法：

1. 用業務實體當 partition key：把需要保序的實體 ID（訂單 ID、帳戶 ID）當 Kafka message key，同 key 雜湊到同 partition、partition 內保序，把「全域有序」收斂成「per-entity 有序」這個多數業務真正需要的粒度。
2. 辨識哪些流真的需要全序：若某條流真的需要全域嚴格有序且無法拆成 per-entity，設單 partition topic（犧牲該 topic 的水平吞吐）；這也是個訊號 — 若大量流都需要全序，遷 Kafka 的吞吐優勢用不上、該重新評估遷移。
3. 規劃 partition 數對齊並行度跟 hot key：partition 數決定 consumer 並行上限，同時注意熱門 key 造成的 hot partition，對位 Kafka topic 設計的 key 策略段。

Case 4：Redis 既有低延遲被 Kafka 吞吐換掉，延遲敏感路徑受傷

徵兆：遷移後某些原本靠 Redis Streams 亞毫秒延遲的路徑（即時風控判斷、撮合前置）延遲跳到數十毫秒，下游 SLA 破線。

根因：Redis Streams 的亞毫秒延遲來自記憶體操作 + 行程內 data structure；Kafka 為了長期保留跟高吞吐，訊息要落磁碟、過 replication、走網路到獨立 broker，單則訊息延遲落在 5-50ms 區間，這是它換吞吐跟持久性付出的代價。把延遲敏感路徑無差別搬上 Kafka，等於用一個為吞吐優化的系統去服務一個為延遲優化的需求。

修法：

1. 按延遲需求分流、不要全遷：把延遲敏感的即時路徑留在 Redis Streams（或 Redis 其他結構）、把需要長保留 / 高吞吐 / replay 的事件流遷到 Kafka，這正是 Bitso 在撮合場景堅持 Redis Streams 的理由。
2. 接受混合架構是常態：Redis Streams 跟 Kafka 共存、各自服務適配的 workload，不追求「全部統一到 Kafka」；對位 Kafka ↔ NATS 的混合架構是 long-term default 思路。
3. 若 Kafka 延遲必須壓低：調 producer linger.ms=0 + acks=1、consumer fetch.min.bytes=1 換取較低延遲，但這會犧牲吞吐與部分可靠性、是 trade-off 不是免費午餐。

Migration 結構：漸進 cutover + 長期混合

這趟遷移的結構是漸進拆分而非一次性切換：先按 workload 性質分流、再對需要遷的事件流做 dual-write 並行、逐流 cutover、最終留下 Redis Streams 跟 Kafka 共存的混合架構。一次性把所有 stream 搬上 Kafka 既無必要、也會把延遲敏感路徑拖下水。

1. Phase 0：scope 分流 — 對每條 stream 跑前面三個訊號的判讀，分成「該遷 Kafka」（retention / replay / 規模超界）跟「留 Redis Streams」（延遲敏感 / 規模在範圍內）兩類。這一步直接決定後續工作量、也避免無差別遷移。
2. Phase 1：Kafka 叢集與 topic 設計 — 建 broker 叢集、依 Case 3 的 partition key 設計建 topic、依 Case 1 的業務需求設 retention，這時做的是基礎設施準備、還沒碰流量。
3. Phase 2：dual-write 並行 — producer 同時寫 Redis Streams 跟 Kafka、新 consumer 接 Kafka 驗證正確性、舊 consumer 持續吃 Redis Streams，這是可逆階段、出問題退回只讀 Redis 即可。
4. Phase 3：逐流 cutover — 逐條 stream 把流量切到 Kafka、確認 consumer 進度（offset）跟 idempotency 都對、再停掉該 stream 的 Redis 端寫入；cutover 以 stream 為單位、不是整批。
5. Phase 4：長期混合 — 留在 Redis Streams 的延遲敏感流跟遷到 Kafka 的事件流共存、各自運維；需要時用 bridge（消費 Redis Streams 寫入 Kafka、或反向）同步必要資料。

dual-write 階段的可逆性是這個結構的安全邊界：在 Phase 2 之前一切可退回純 Redis、Phase 3 逐流 cutover 把不可逆動作（停 Redis 寫入）切到最小粒度，單條 stream 出問題不影響其他流。

Capacity / cost 對照

判讀：成本的核心翻轉在「儲存成本曲線」這列。Redis Streams 把資料壓在最貴的 RAM、retention 越長越貴，所以實務上被迫短保留；Kafka 把資料攤到便宜的磁碟、再分層到 S3，讓長保留變得可負擔。但這個翻轉只在「retention 需求真的長」時成立 — 若 retention 只需數小時、資料量小，Redis Streams 沒有獨立叢集跟 0.5-2 FTE 的運維增量，總成本反而低，這正是 Arcjet 的處境。遷移划不划算取決於 retention 跟規模需求落在這條曲線的哪一段。

整合 / 下一步

混合架構是常見終態

多數從 Redis Streams 起步、因規模長出 Kafka 需求的系統，終態是兩者共存而非取代：

1[延遲敏感即時路徑]                    [長保留 / replay / 高吞吐事件流]
2   Redis Streams                              Kafka
3        │                                       │
4        └──────────── Bridge（雙向同步）────────┘

Redis Streams 服務亞毫秒延遲的即時路徑（風控、撮合前置）、Kafka 服務需要長保留與 replay 的事件流；需要打通時寫一段 bridge 同步必要 stream。這跟 Kafka ↔ NATS 的混合架構是 long-term default 是同一個 paradigm shift 結論的兩個實例。

接上 Kafka 生態

遷到 Kafka 後可解鎖 Redis Streams 沒有的生態能力：

• Schema 治理：用 Schema Registry 強制 producer / consumer 契約，補上 Redis Streams 缺的 schema enforcement（對位 Bitso 自建抽象層的紀律性責任）。
• CDC pipeline：接 Debezium 把資料庫變更流進 Kafka topic，做事件溯源主軸。
• 長期 replay：tiered storage 把冷事件分層到 S3、支援數年 replay。

反向確認的 tripwire

遷移後若觀察到：延遲敏感路徑 SLA 破線、Kafka 叢集運維成本超出省下的 RAM 成本、實際 retention 需求遠短於規劃 — 這些是「該遷的訊號其實不成立」的回溯訊號，應重新評估該 stream 是否該退回 Redis Streams，對位 Arcjet 的成本判讀。

相關連結

• Source / target vendor：Redis Streams / Kafka
• 反向案例：Arcjet Redis Streams 取代 Kafka / Bitso Reliable Streams / Learning.com 退場
• 平行 migration playbook（同 paradigm shift）：Kafka ↔ NATS
• 平行 vendor：RabbitMQ / NATS
• Methodology：Migration Playbook 寫作方法論（Type E paradigm shift）

本文是跨 vendor migration playbook、cross-link 到 Kafka 跟 NATS。跟前四篇 migration（schema 差 / drop-in / operational redesign / multi-tool 拆分）對照、本篇是 paradigm shift — 兩端不是「同類產品的不同實作」、是 不同抽象層的 messaging system。

「Kafka → NATS migration」字面上不成立

前面四篇 migration 都隱含一個前提：source 跟 target 是 同類產品、只是不同實作或 deployment 模型。「Kafka → NATS」字面上看起來也是 messaging migration、但實際上：

Kafka 跟 NATS Core 是 不同類產品 — 一個是 durable event log、一個是 transient pub/sub。「migration」需要先決定 target 是 NATS Core 還是 JetStream、然後判斷 application 模式能否重設計 對應。

什麼情境真的能換、什麼不能

判讀：

• Microservice async messaging + 低延遲需求 → NATS Core 更合適、是 真正的 migration
• Event sourcing + replay → JetStream 部分對等、但 partition / offset 觀念變了
• Log collection / event streaming → 不該遷、保留 Kafka

為什麼會考慮這個 paradigm shift

實務上觸發評估 NATS 通常三條 driver：

1. Cost + operational complexity：Kafka cluster + ZooKeeper（或 KRaft）+ Schema Registry + Connect 是重資產、3-5 broker + ops 1+ FTE；NATS 單 binary、無依賴、輕量
2. Latency 要求 < 1ms：Kafka 對單 message latency 不是 SLA、NATS Core 是
3. Multi-tenant / multi-region 簡化：NATS 內建 account + leaf node 拓樸、跨 region 是 first-class

但這三條 driver 都 只在特定 application 模式有效。不是普世 better、是 某類 workload 適合。

Migration 結構：application 重設計 + 部分 stream cutover

跟前面四篇 migration 結構都不同、Kafka ↔ NATS 是 混合：

1. Phase 0：scope 判讀 — 列 application、區分「適合 NATS」vs「保留 Kafka」
2. Phase 1：application code 重設計 — 不是 SDK 換、是 messaging pattern 改（event sourcing → message bus / consumer group → durable consumer）
3. Phase 2：部分 stream parallel run — 新 application 走 NATS、舊 application 持續 Kafka
4. Phase 3：cutover 適合的 stream
5. Phase 4：長期混合架構 — Kafka 跟 NATS 共存、不消滅一邊

整體不是 一次 migration、是 漸進拆分。多數 production 環境 永遠 是混合架構。

Application 重設計範例：consumer group → durable consumer

 1// Kafka 端 consumer group pattern
 2consumer := kafka.NewConsumer(&kafka.ConfigMap{
 3    "bootstrap.servers": "kafka:9092",
 4    "group.id":          "myapp-orders",
 5    "auto.offset.reset": "earliest",
 6})
 7consumer.SubscribeTopics([]string{"orders"}, nil)
 8
 9for {
10    msg, err := consumer.ReadMessage(-1)
11    // process msg.Value
12    consumer.CommitMessage(msg)
13}

 1// NATS JetStream durable consumer
 2js, _ := nc.JetStream()
 3sub, _ := js.PullSubscribe("orders.>", "myapp-orders",
 4    nats.AckExplicit(),
 5    nats.MaxAckPending(100),
 6)
 7
 8for {
 9    msgs, _ := sub.Fetch(10, nats.MaxWait(5*time.Second))
10    for _, msg := range msgs {
11        // process msg.Data
12        msg.Ack()
13    }
14}

差異：

• Kafka auto.offset.reset → NATS DeliverPolicy（多種選項）
• Kafka commit message → NATS explicit Ack（per message）
• Kafka partition → NATS subject hierarchy（orders.> 通配）
• Kafka rebalance → NATS 不需要、durable consumer 跨 instance 共享

Application 邏輯改動 30-60%、不是 SDK 換。

Production 故障演練

Case 1：Consumer offset 觀念差，replay 不對等

徵兆：application 設計「跑歷史 7 天事件 catch-up」、Kafka 設 auto.offset.reset=earliest + seek_to(timestamp) 跑；換 NATS JetStream 後找不到 seek_to 等價 API、catch-up 失敗。

根因：Kafka offset 是 broker-side 維護 + consumer-side commit；NATS JetStream 用 sequence number + DeliverPolicy.ByStartTime、但 time-based seek 精度低、且 application code 必須改。

修法：

1. 預先設計：NATS JetStream 用 DeliverPolicy.ByStartSequence + 自管 sequence-time mapping
2. 保留 Kafka 給 replay-heavy use case：不是所有 application 都遷
3. 混合架構：歷史 replay 走 Kafka、新事件流走 NATS、application 處理雙來源

Case 2：Retention model 差異、磁碟使用炸

徵兆：NATS JetStream stream 設 retention=interest（subscriber 收到就刪）、cutover 後 disk 持續長大；預期跟 Kafka log retention 7 天類似、實際資料留 30+ 天沒清。

根因：NATS JetStream retention 有 3 種：limits / interest / workqueue。interest 是 至少一個 subscriber 還沒 ack 就保留；application 端 silent consumer（已下線但沒 unsubscribe）讓 message 永留。

修法：

1. 預設 retention=limits：用 MaxAge / MaxBytes 跟 Kafka log retention 對應、明確控制
2. interest retention 慎用：只在 確認所有 subscriber lifecycle 受控 場景
3. Subscriber cleanup：application graceful shutdown 必須主動 unsubscribe、不留 zombie consumer

Case 3：Exactly-once 假設不對等

徵兆：cutover 後發現某 application（payment processor）開始出現 duplicate transaction；Kafka 端用 transactional producer + idempotent consumer 跑了 2 年沒問題。

根因：Kafka exactly-once 是 producer transaction + consumer offset commit atomic；NATS JetStream exactly-once 概念不一樣 — 是 publish ack + consumer ack 跨層 atomic、application 端要主動處理 idempotency。

修法：

1. 重新審視 application 端 idempotency：用 message ID + dedup store（Redis SETEX）顯式 dedup
2. NATS JetStream 對 exactly-once 不該假設「自動」：application 端責任、不是 broker 端
3. Payment / financial 場景慎遷：保留 Kafka transactional pattern 較穩

Case 4：Schema registry 缺位、ad-hoc schema 漂移

徵兆：NATS 部署 3 個月後、producer / consumer 間 schema 對不上、application bug；Kafka 端有 Confluent Schema Registry 強 enforce、NATS 沒對等服務。

根因：NATS 哲學是 minimalist、不內建 schema registry；application 自己決定 payload format。Kafka 生態的 Avro / Protobuf + Registry 模式不直接搬。

修法：

1. 外部 schema management：用 BSR（Buf Schema Registry）或自家 Git-based registry、producer / consumer build-time 驗證
2. NATS Object Store：JetStream 提供 K/V + Object Store、可存 schema 文件
3. 接受紀律性 trade-off：NATS 簡潔代價是 application 端紀律、不能靠 broker 強 enforce

Case 5：Fan-out 模式跟 Kafka 不一致

徵兆：同一 event 要送 5 個 downstream service、Kafka 端用 consumer group + 5 個 group 跑；NATS 端設計 5 個 durable consumer、結果某些 message 漏 fan-out。

根因：Kafka consumer group 對 同 group 內 partition 分配、不同 group 各自完整消費；NATS JetStream Durable consumer 預設行為跟 group 不同 — 單 durable consumer 是 shared subscription、要 fan-out 需多個獨立 durable。

修法：

1. 明確設計 fan-out：N 個 downstream 對應 N 個 獨立 durable consumer、不共用
2. 用 AckPolicy.None + push subscriber：不需要 ack 的 fan-out 場景、用 ephemeral push subscriber
3. 檢查 application stream config：fan-out 失敗多半是 consumer config 錯、不是 NATS bug

Capacity / cost 對照

判讀：簡單 messaging workload NATS 顯著便宜；complex event streaming（Schema Registry / Streams / Connect 重度用）Kafka 不替代。

整合 / 下一步

混合架構是 long-term default

多數 production 環境最終是 Kafka + NATS 共存：

1[event sourcing / log collection]        [microservice async messaging]
2         Kafka                                       NATS
3         │                                            │
4         └──────── Bridge (Connect / Custom) ────────┘

NATS 跑微服務間 messaging、Kafka 跑 event log / analytics pipeline；中間用 Kafka Connect NATS connector 或自寫 bridge 同步必要 stream。

跟 Logical Replication + Debezium 對位

CDC pipeline 設計：

• DB → Debezium → Kafka topic（event sourcing 主軸）
• Kafka → NATS bridge → microservice fan-out
• 不直接 DB → Debezium → NATS（Debezium 不原生支援 NATS sink）

跟前 4 篇 migration 的結構對照

結論：migration 結構由 最大差異維度 決定、不是 universal phased playbook。

相關連結

• Source / target vendor：Kafka / NATS
• 平行 vendor：RabbitMQ / Redis Streams
• 平行 migration playbook：Splunk → Elastic Security / Redis → DragonflyDB / PostgreSQL → Aurora / Datadog → Grafana Stack
• Methodology：Vendor 深度技術文章的寫作方法論