為什麼要接訊息平台

服務的通知管道除了 App 推播，還接了一個大眾普及率極高的訊息平台官方帳號。理由很實際：使用者不一定裝 App，但幾乎人人都用這個訊息平台——通知到達率跟開啟率是 email 比不上的。

但接上之後第一件要搞懂的事，不是 API 文件，是計費模型。它直接決定了你的功能該長什麼樣。

兩種訊息，兩種成本

這類平台的計費結構幾乎都是同一個形狀：

這個不對稱是平台的商業設計，但對開發者來說，它是一條清晰的架構指南：能設計成「使用者來問、系統回答」的功能，就不要設計成「系統主動通知」。

實際的設計取捨

同一個需求，兩種形狀的成本差異是「零 vs 每月固定失血」：

• 查詢類功能（看目前狀態、查紀錄、看摘要）→ 全部做成選單／指令觸發的 reply。使用者點一下、系統回一則，零成本，而且使用者主動來查時的注意力品質本來就比被動收到通知高
• 真正的時效性通知（條件觸發的警報、到期提醒)→ 才用 push。判斷標準一句話：錯過這個時機，這個資訊就沒價值了嗎？ 是，才配用 push；否則做成使用者下次來查得到的東西

這條原則寫進專案規範後變成鐵律：新功能預設走免費 reply，要用 push 必須先論證時效性。 幾個月下來，訊息成本一直壓在個位數百分比的佔比——不是靠省，是靠架構。

進一步：使用者分級的推播額度

push 既然是稀缺資源，它的分配也接進了 Day 14 的等級對照表：不同訂閱等級有不同的推播額度，用點數機制（Day 16）計量。這讓成本結構跟收入結構對齊——重度使用推播的使用者，是付了對應費用的使用者。

免費使用者也有基本額度，但超出後會收到「本期額度已用完」的 reply（免費的！）而不是靜默失效——任何因額度而降級的行為，都要讓使用者知道原因，靜默失效是客服工單的孵化器。

通則

接任何按量計費的第三方服務，第一件事是把計費模型翻譯成架構約束：哪種用法免費、哪種燒錢，然後讓「預設路徑」落在免費側。 成本控制做在架構層是一勞永逸，做在營運層是每天打地鼠。而架構層做完之後，還需要最後一道保險——萬一程式邏輯出錯瘋狂發送呢？那就是明天的主題：斷路器。