---
# System prepended metadata

title: 對接技術方案Plan B

---

對接技術方案Plan B
===

RTI、TP FE、TP BE交互情境
---
**最左邊的E指的是情境*
```sequence
Note left of RTI: E:TP從RTI訂閱賠率
RTI->TP Backend: GraphQL 訂閱賽事、賠率
RTI->TP Backend: 賽事、賠率更新
Note right of TP Backend: 沒有調賠，將數據源當成S水
Note right of TP Backend: 更新DB&Redis(S水)
Note right of TP Backend: 推送新水給訂閱方
TP Backend->TP Frontend: 最新的S水+Config
TP Backend->RTI: 最新的S水
Note left of RTI: E:數據源賠率更新
RTI->TP Backend: 賽事、賠率更新
Note right of TP Backend: 沒有調賠，將數據源當成S水
Note right of TP Backend: 更新DB&Redis(S水)
Note right of TP Backend: 推送新水給訂閱方
TP Backend->TP Frontend: 最新的S水+Config
TP Backend->RTI: 最新的S水
Note left of RTI: E:操盤手調賠(成功)
TP Frontend->TP Backend: 送出賠率調整(Config)
Note right of TP Backend: Validator
Note right of TP Backend: Config存入DB
Note right of TP Backend: 數據源＋Config後，得出S水
Note right of TP Backend: 更新DB&Redis(S水)
Note right of TP Backend: 推送新水給訂閱方(FE+RTI)
TP Backend->TP Frontend: 最新的S水+Config
TP Backend->RTI: 最新的S水
TP Backend->TP Frontend: 調賠Response，提示調整成功
Note left of RTI: E:數據源賠率更新(需混水)
RTI->TP Backend: 賽事、賠率更新
Note right of TP Backend: 數據源＋Config後，得出S水
Note right of TP Backend: 更新DB&Redis(S水)
Note right of TP Backend: 推送新水給訂閱方(FE+RTI)
TP Backend->TP Frontend: 最新的S水+Config
TP Backend->RTI: 最新的S水
Note left of RTI: E:操盤手調賠(失敗)
TP Frontend->TP Backend: 送出賠率調整(Config)
Note right of TP Backend: Validator
Note right of TP Backend: Config存入DB(*失敗*)
TP Backend->TP Frontend: 調賠Response，提示調整失敗
Note left of RTI: E:操盤手調賠(失敗)
TP Frontend->TP Backend: 送出賠率調整(Config)
Note right of TP Backend: Validator
Note right of TP Backend: Config存入DB
Note right of TP Backend: 數據源＋Config後，得出S水(*失敗*)
Note right of TP Backend: DB Config Rollback
TP Backend->TP Frontend: 調賠Response，提示調整失敗
Note left of RTI: E:操盤手調賠(失敗)
TP Frontend->TP Backend: 送出賠率調整(Config)
Note right of TP Backend: Validator
Note right of TP Backend: Config存入DB
Note right of TP Backend: 數據源＋Config後，得出S水
Note right of TP Backend: 更新DB&Redis(S水)(*失敗*)
Note right of TP Backend: DB Config Rollback
TP Backend->TP Frontend: 調賠Response，提示調整失敗
Note left of RTI: E:操盤手調賠(成功)
TP Frontend->TP Backend: 送出賠率調整(Config)
Note right of TP Backend: Validator
Note right of TP Backend: Config存入DB
Note right of TP Backend: 數據源＋Config後，得出S水
Note right of TP Backend: 更新DB&Redis(S水)
Note right of TP Backend: 推送新水給訂閱方(FE+RTI)(*失敗*)
Note right of TP Backend: 發Slack通知技術端
TP Backend->TP Frontend: 調賠Response，提示調整成功
Note left of RTI: E:用戶發起Query
TP Frontend->TP Backend: 發起Query
Note right of TP Backend: 到Redis取得對應資料
TP Backend->TP Frontend: 返回S水
```

### 主要問題：
- 訂閱RTI數據源後，TP需要自己保留、管理一份賠率資料
- S水的路徑是RTI -> TP -> 混水 -> RTI -> Inno路徑較長


### 優點：
- 兩套系統耦合度低很多，架構也相對單純
- 操盤手的操作，包transaction，可以明確知道成功失敗
- 關於混水、調賠的規則，不需要兩邊都做
- 前端邏輯減少，對接的後端or服務，收斂到TP Backend一個
- 減少技術棧數量，Realtime DB是目前公司尚未使用的技術
- 新的需求加入，僅需調配TP的人力及時程安排
- Trouble Shooting時，權責劃分很清楚，只要S水有問題，都是找TP先