這篇對照的核心責任是說明 queue 選型要跟著流量與組織規模改變。

小型服務常見判讀

小型服務優先用 managed queue 往往最穩，因為運維成本最低。這時候最容易忽略的是語義邊界：重試次數、死信規則、重播責任如果沒先定義，規模一上來就會出現資料重複與漏處理。

中型服務常見判讀

中型服務常見問題是 lag 與 DLQ 長期累積。根因通常是 consumer idempotency、重播流程、下游承載能力沒有一起設計，broker 效能本身很少是單點問題。

大型服務常見判讀

大型服務需要處理跨租戶與跨區壓力。此時若還用單叢集思維，任何一類流量尖峰都會拖垮整體。重點會從「怎麼送訊息」轉成「怎麼隔離失敗」。

這個情境的專屬告警條件

• consumer lag 連續超出 SLO 窗口
• DLQ 速率上升且無法在固定時間內回收
• 重播後仍出現相同失敗模式

出現上述條件應先凍結切換，回到前一語義設定，再逐步修正 consumer 契約與重播流程。