客戶分群與會員忠誠度服務
客戶分群、會員等級回饋與合作夥伴返利設定
專案背景
每個租戶都希望依客戶行為（例如儲值金額）提供差異化對待，並能自行設定。分群必須在使用者註冊當下就指派，定期針對每個租戶與幣別重新評估，並可在留有稽核軌跡的前提下手動調整。
架構設計
管理 API（閘道）→ 客戶分群 gRPC 服務 → MySQL（設定、指派、歷史、策略資料表）。身分服務的註冊事件 → Kafka 消費者 → 預設指派。排程任務服務中的每日 Temporal 工作流程 → 各租戶/幣別的子工作流程 → 分類結果發布到 Kafka → 由具重試與死信 Topic 的消費者套用。
核心技術亮點
從零打造客戶分群：9 張資料表、28 個 gRPC 與 16 個 HTTP 端點、以交易保證且預設分群唯一的設定、附快照的變更歷史
新使用者透過 Kafka 註冊事件取得預設分群；依滾動期間儲值門檻進行規則式自動分類
每日執行的 Temporal 工作流程，以各租戶的子工作流程及具心跳、分頁的 activity，對每個租戶與幣別重新分類
針對不限層數合作夥伴網路的返利設定：逐層費率、Redis cache-aside 搭配 pipeline 批次失效，以及產品啟用時由 Kafka 驅動產生預設值
冪等的回饋紀錄消費者：以唯一索引保證的確定性鍵值
核心實現
以事件進行預設指派
Kafka 消費者訂閱使用者註冊與使用者建立事件，指派該租戶的預設分群，並配有重試與死信 Topic。
Why: 指派不能仰賴註冊請求中第二次寫入的成功；以事件驅動指派，讓身分與分群保持解耦。
可續跑的重新分類
每日工作流程列出所有租戶，並為每個租戶與幣別啟動一個子工作流程。每個子工作流程載入升級對照表與降級策略，分頁走訪使用者並回報 activity 心跳，最後發布結果。
Why: 重新評估所有使用者是長時間執行的工作；心跳與分頁讓 Temporal 能重試或接續單一子工作流程，不必重跑整個流程。
合作夥伴返利設定
針對不限層數合作夥伴網路的逐層費率規則，快取於 Redis 並以租戶為範圍整體失效；查詢時平行解析使用者整條合作夥伴鏈上的費率。
Why: 結算工作需要每位使用者的完整鏈路；快取與平行查詢讓成本維持在低水準。
技術決策
| 技術決策 | 選擇 | 替代方案 | 原因 |
|---|---|---|---|
| 分類在哪裡執行 | 由 Temporal 工作流程執行，並將結果發布到 Kafka | 在客戶分群服務內以 cron 分類 | 各租戶的長時間執行需要重試、可視性與可續跑能力；發布結果則讓寫入路徑集中在單一消費者。 |