"Paradigm"
- Deterministic vs Fuzzy engineering
LLM 軟體 vs 傳統軟體在資料 / 邏輯 / 行為一致性 / 實驗成本四維度的典範差異、決定哪段該包 guardrail
- 0.8 Deterministic vs Fuzzy Engineering：軟體設計典範的位移
傳統 deterministic 軟體跟 fuzzy LLM 軟體在資料、邏輯、分解、實驗成本四個維度的根本差異、以及哪段該 deterministic、哪段該 fuzzy 的決策框架
- 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 與長期混合架構
- 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
- 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 對位 + 混合架構