這個案例的核心責任是說明原生 push subscription 在特定場景的限制、逼出自建層的工程選擇。

觀察

全球商品同步系統、自建 in-house「PubSub gRPC Pusher」（Pub/Sub 的 gRPC 版 push subscription）解決高吞吐 / 長 job / 彈性 RPS；同時用 message ID 做去重、timestamp 驗證解決重複 + 亂序。

判讀

原生 HTTP push subscription 在「長 job + 高吞吐 + 動態 rate」場景的限制、逼出自建層的工程選擇。揭露 managed broker 的「原生功能」不是所有場景的終點。

對應大綱

Pub/Sub 進階主題：Push vs Pull subscription / Ordering key（亂序的 application-level 處理）。

下一步路由

回 Pub/Sub vendor 頁 與 3.4 consumer 設計。

引用源