非同步決策的核心原則是先定義投遞語意，再選擇傳遞工具。queue、stream、pub/sub、outbox、retry、dead-letter、replay 與 idempotency 是同一條決策鏈，不是獨立名詞清單。

本章目標

學完本章後，你將能夠：

1. 用事件生命週期描述非同步需求
2. 區分「可延遲」、「可重試」、「可重播」與「可去重」的責任邊界
3. 把訊息系統術語串成可檢查的決策流程
4. 判斷目前停在概念層，還是已經進入實作層

【判讀】事件生命週期先於產品選型

事件設計的核心問題是「事件在系統裡如何出生、傳遞、處理、失敗、重試與回放」。先回答生命週期，才有辦法判斷是否要用 broker、queue 或 stream。

一條最小生命週期通常包含：

1. 產生：producer 何時發布事件
   參考：Producer / Outbox Pattern
2. 傳遞：事件放在哪種通道
   參考：Queue / Topic / Broker
3. 消費：consumer 如何確認處理結果
   參考：Consumer / Ack/Nack
4. 失敗：重試與隔離如何發生
   參考：Retry Policy / Dead-Letter Queue
5. 回復：資料如何補送與重播
   參考：Replay Runbook / Offset

這條鏈路完整後，才進入 RabbitMQ、Kafka、Redis Streams 或雲端託管服務比較。

【判讀】投遞語意決定設計強度

投遞語意的核心問題是「失敗後，系統接受哪種結果」。at-most-once、at-least-once 與順序需求會直接決定重試、去重與補送成本。

接近真實網路服務的判斷方式包括：

• 通知類訊息可接受少量遺失：重點在低延遲與 fan-out。
• 金流或庫存狀態不可遺失：重點在持久化、重試與補償，並定義 strong reliability 路徑。
• 分析事件可接受短暫延遲：重點在可重播與批次處理。

對應卡片：

• Duplicate Delivery
• Idempotency
• Message Persistence
• Delivery Mode

【判讀】壅塞與延遲要用同一組語言處理

非同步壓力的核心問題是「輸入速度高於處理速度」。這會同時反映在 queue depth、consumer lag、timeout 與重試風暴。

對應卡片關係：

• 壓力來源：
  Backpressure / Queue Depth / Consumer Lag
• 保護策略：
  Rate Limit / Load Shedding / Circuit Breaker
• 失敗擴散：
  Retry Storm / Cascading Failure

這一層討論完成前，不需要先決定 broker 產品或 partition 數量。

【判讀】回復流程是可靠性設計的一部分

回復設計的核心問題是「錯誤發生後如何回到正確狀態」。DLQ、replay、Data Reconciliation 與 runbook 應該一起定義。

對應卡片：

• Dead-Letter Queue
• Replay Runbook
• Data Reconciliation
• Runbook

若這些概念只有名詞而沒有決策順序，系統上線後會把排障責任推給個人經驗。

【邊界】何時從概念章節進入實作章節

當以下問題都能回答時，代表概念層已完成，可以進入實作模組：

1. 哪些事件可遺失，哪些事件不可遺失
2. 哪些 consumer 需要去重，語意鍵是什麼
3. 何時重試、何時進 DLQ、何時啟動 replay
4. 哪些指標觸發擴容或降級

下一步建議路由：

• 進入訊息系統能力比較：03-message-queue
• 進入可觀測與事故流程：04-observability / 08-incident-response