Vendor / Platform 清單

實作時的常用選擇見 vendors — T1 收錄 RabbitMQ / Kafka / NATS / Redis Streams / AWS SQS / Google Pub/Sub，每個 vendor 有定位、適用場景、取捨與預計實作話題的骨架。

Deep article（vendor 自身的配置、故障、容量）跟 migration playbook（跨 vendor 遷移流程）的撰寫進度見 vendors/ 的「內容覆蓋進度」段。

暫定分類

選型入口

訊息佇列選型的核心判斷是工作離開 request 或 process 後需要什麼投遞保證。當工作需要排隊、重試、跨服務傳遞、多 consumer 協作或事件補送時，broker 與 outbox 值得優先評估。

RabbitMQ 適合明確 routing、ack/nack 與工作佇列；NATS 適合 subject-based messaging 與較輕量的服務通訊，搭配 JetStream 可加入持久化；Kafka 適合高吞吐事件流、partition 與長期 replay；Redis Streams 適合 Redis 生態內的 stream 與 consumer group；outbox 解決資料寫入與事件發布的一致性；idempotency 解決重複投遞造成的結果穩定性；retry budget 與 jitter 則控制故障期間的重試壓力。

接近真實網路服務的例子包括付款後寄信、影片轉檔、訂單事件傳給多個系統、IoT readings pipeline 與跨節點通知。這些場景的共同問題是 delivery semantics，因此本模組會先處理 broker 模型、retry、DLQ、outbox 與 consumer 設計。

與語言教材的分工

語言教材處理本地 backpressure、processor 邊界、port / Message Protocol 設計與單一 process 內的去重。Backend message queue 模組處理 broker selection、ack/nack、DLQ、consumer group、outbox 與跨 process 重試。

案例驅動讀法

佇列案例的核心讀法是先辨識遷移的是「資料路徑」還是「治理路徑」，再決定先做 broker 切換還是治理收斂。

跨語言適配評估

訊息佇列使用方式會受語言的 worker model、錯誤處理、序列化、背景任務框架與 idempotency 設計影響。同步 runtime 要控制 consumer thread 數量與 ack timeout；async runtime 要處理 backpressure 與 long-running handler；輕量並發 runtime 要限制同時處理量，避免 consumer 擴張超過下游容量。強型別語言適合建立 event schema 與 command model；動態語言要補足 payload validation、dead-letter 診斷與重播測試。

章節列表

反例與規模對照入口： 3.C9 反例 / 3.C10 對照。

回退判讀寫法見 0.C4 回退判讀寫法，queue 案例要優先保留 delivery semantics、lag、DLQ 與 replay 條件。

跨模組端到端串聯（DB → cache → event → observability）見 0.15 跨模組 Checkout Episode。

觀念網路補完方向

訊息佇列章節下一輪的核心責任是把「投遞成功」和「業務結果正確」分開。現有章節已經有 broker、durable queue、outbox 與 consumer design，但還需要補上 delivery semantics、processing semantics 與 recovery semantics 的三層關係，讓讀者知道 queue 失敗同時包括訊息遺失、重複副作用、順序錯亂、重播風險與下游壓力放大。

這些方向要用非同步服務自己的語意展開。寄信、開 invoice、更新 CRM、同步 search index、發 webhook 的副作用不同，retry、DLQ 與 replay 的判準也不同。

知識卡補強方向

佇列模組的 knowledge card 缺口集中在「處理語意」與「恢復語意」。已有 consumer lag、retry budget、poison message 與 offset 可以作為第一批錨點。

第二批卡片已補上 processing semantics、recovery semantics、replay window、consumer pause、event schema compatibility、DLQ drain 與 poison-message quarantine。這些卡片讓讀者能分辨「queue 有持久化」和「consumer 結果可恢復」分屬不同責任。

實作探討入口

佇列的第一條實作路徑是 3.8 Queue Consumer Retry 與 Replay Handoff（實作示範）。這篇以 order_created consumer 為例，說明 idempotency evidence、DLQ handling、replay runbook 與 incident decision route 如何一起成立。

這條路徑的前置引用應該是 3.2 durable queue、3.3 outbox pattern、3.4 consumer design、6.12 Idempotency 與 Replay 驗證 與 6.23 Verification Evidence Handoff。完成後可依 Backend 學習路線 進入下一條服務路徑。

佇列路徑的 artifact 對齊重點是「把投遞成功與處理成功拆開記錄」。對 4.20 要交 Source/Time range/Query link/Owner/Data quality，並覆蓋 consumer lag、retry、DLQ 與 duplicate side-effect；對 6.12 / 6.23 / 6.8 要交 Gate decision/Checks/Stop condition/Rollback window/Owner，呈現 replay 範圍、去重驗證與補償路徑；對 8.19 要交 Timestamp/Decision/Context/Evidence/Owner/Expected effect/Rollback condition，記錄 pause consumer、drain DLQ、重播啟停的決策序列。