訊息基礎設施好少因為揀錯供應商而出事。真正原因係一組決策從來冇明確嘅負責人，於是被嗰個星期做緊 integration 嘅人靜靜寫咗入代碼。電訊商政策、供應商產品、計費同法規按市場以唔同節奏變化，所以下面每一項具體要求都要對照當前一手資料再核實。
面向應用嘅契約同渠道適配器
應用應該只認識一個內部介面——提交訊息、接收狀態——將所有同供應商相關嘅細節都收埋喺一個適配器背後，由佢負責翻譯請求、將狀態同錯誤映射到統一詞彙表，並上報自身健康狀況。負責人： 工程團隊，訊息營運團隊定義狀態同錯誤詞彙。
路由供應：自有路由、BYOV 或混合
存在三種模式，並且互不排斥：由人哋為你採購同營運嘅供應路由；BYOV，即係你保留自己同供應商嘅合約，由託管層營運網關、路由同升級處理；以及混合模式，按市場或者作為第二條 failover 路徑組合前兩者。負責人： 採購同訊息營運共同負責。
發送方身分同按市場註冊
發送方註冊係按市場進行嘅項目，唔係一個設定欄位，各自有自己嘅時限、審核、到期同續期規則，喺唔同供應商之間通常唔可以直接搬過去。應該維護一份記錄每個身分同其狀態嘅台帳。負責人： 訊息營運，品牌同內容聲明由法務參與。
統一狀態模型同 DLR 嘅局限
應採用自有嘅一套狀態同原因集合，同時保留供應商原始值用嚟排查，並對未映射嘅值落 alert。送達回執只係網絡層面嘅證據，唔係結果本身；真正嘅目標——驗證碼已輸入、預約已確認、款項已支付——要喺應用層度量。對遺失最終狀態嘅對帳工作係呢個決策嘅一部分，而唔係可有可無嘅附加項。負責人： 工程同訊息營運共同負責；產品定義結果。
路由策略、隊列隔離、重試、幂等同 failover
路由應該係設定，唔係代碼，先可以喺事故中快速反應。需要按流量類別隔離隊列（避免一次 marketing 批量拖慢一次性驗證碼）、明確重試規則同邊個負責重試、用自有引用做幂等鍵，並定義 failover 嘅觸發條件、備用路徑同去重規則。負責人： 訊息營運負責策略；工程負責實現機制。
按路由監控、金絲雀探測同事故歸屬
匯總送達率會遮住單條路由嘅失敗。需要喺同一時間窗口比較唔同路由，並用實時金絲雀探測發現靜默過濾或者基於內容嘅攔截。邊個宣布事故、邊個負責同供應商升級溝通、邊個決定 failover，都應該提前講清楚。負責人： 訊息營運，配有指定嘅 on-call 機制。
電訊商政策變更管理、計費同範本治理
電訊商要求嘅變化通常預告期好短；需要 按市場同供應商指定負責人，並維護一份營運依賴關係台帳。計費按單位結算——有時按對話或會話計——所以要自建按段計費嘅記錄同帳單核對，因為一次編碼方式嘅改動就可以喺冇人察覺嘅情況下令可計費段數倍增。Consent、抑制、留存同範本治理都需要有明確嘅控制項同負責人，而唔係籠統咁話合規。
託管層嘅定位
Flowstates 提供並營運訊息路由同渠道，透過 BYOV 支援客戶自有嘅供應商，亦支援混合部署，負責營運網關、路由、監控、註冊、供應商升級處理同對帳。唔會轉移嘅係結果定義、consent 採集同產品流程——呢啲始終留喺應用層。無論如何，呢啲決策都必須有人做出；唯一嘅問題係團隊係主動揀，定係被動繼承咗佢。