系統設計面試題：如何設計即時支付反詐欺平台？

題目與適用情境

請設計一個即時支付反詐欺平台。它位於付款授權之前，對每次請求回傳 ALLOW、STEP_UP、REVIEW 或 BLOCK。STEP_UP 要求額外身分驗證；REVIEW 可以延後履約或其他可逆的業務動作，但反詐欺服務 本身不執行資金扣款。

假設系統平均每秒接收 1,000 個請求，尖峰每秒 5,000 個，每個請求約 1.5 KB。同步決策的 p99 低於 100 毫秒，每月可用性目標為 99.99%。營運團隊每天最多人工審查 10,000 個案件。決策紀錄保留七天供 即時查詢，原始事件封存 400 天。這些數字是面試假設，不代表真實產品指標或法定保留期限。

付款服務傳送代碼化付款工具、帳戶、商家、裝置、網路、金額、幣別和事件時間等屬性。反詐欺平台不得 接收原始卡號或安全碼。它負責風險決策、規則與模型版本、線上風險特徵、審查案件和回饋標籤；付款授權、 3DS 執行、拒付與資金帳本仍由各自系統負責。

面試官考察什麼

第一項訊號是候選人能否定義決策契約，而非只最佳化模型準確率。詐欺損失、誤擋正常使用者、額外驗證 摩擦、人工審查容量、延遲和可用性共同約束策略。模型分數只是證據；帶版本的策略負責把證據轉成動作。

第二項訊號是時間正確性。速率特徵要包含目前這次嘗試，又不能在冪等重試時重複計數。歷史訓練特徵只能 使用原決策發生時已經可用的資訊。拒付和審查結果會延遲抵達，因此未標記交易不能立刻當成負樣本。

第三項訊號是同步路徑是否有明確邊界。關鍵路徑只做身分與結構驗證、批次讀取一小組特徵快照、執行規則 與一個正式模型、套用策略、持久化可重播決策並回傳。全域圖遍歷、大型聯結、模型訓練和案件分析都應移出 關鍵路徑。圖或批次工作把精簡的風險特徵預先發布給同步服務讀取。

第四項訊號是降級規則是否明確。過期特徵不等於安全特徵，模型缺失也不等於風險分數為零。動作要依照 特徵新鮮度、金額、受影響實體和現有備援能力改變。高品質回答會說明每個相依服務故障時，何時放行、 加強驗證、送審或阻擋。

最後是方案能否被證偽。每個決策都記錄請求摘要、特徵來源、命中規則、模型與策略版本、分數、動作、 原因碼和延遲。這樣才能用歷史重播、時間點特徵核對、重複與亂序事件、熱點鍵壓力、相依服務故障、對抗 流量、影子流量和小流量發布檢驗設計。

回答前要確認的問題

• 平台放在哪個環節？ 本方案在授權前同步決策。純非同步偵測器可以發現團伙並支援調查，但阻止不了

目前這筆付款。

• 可用動作有哪些？ 題目給出四種動作。REVIEW 受到每天 10,000 個案件的硬上限約束，不能把每個

不確定分數都丟給人工。案件等待期間哪些業務動作可以撤銷，由支付產品定義。

• 上游提供哪些識別碼？ 要求穩定的 decision_id、代碼化付款工具 ID、存在時的帳戶 ID、商家 ID

和裝置 ID。原始卡片資料不進入邊界；缺少的選用身分要變成明確特徵，不能捏造預設值。

• 特徵要多新？ 十分鐘速率規則不能使用一小時前的計數。每組特徵都有最大允許年齡和備援策略；輪廓

特徵也許能容忍數分鐘，關鍵速率狀態可能只能容忍數秒。

• 標籤何時、如何抵達？ 審查員結論是較早但可能出錯的訊號，之後確認的拒付是更強標籤。應保存標籤

來源、觀察時間、成熟狀態和版本，後續修正不能悄悄改寫歷史。

• 跨實體圖偵測是否同步執行？ 在 100 毫秒預算內不做全域遍歷。離線或串流圖工作發布實體風險、

鄰居風險等精簡特徵；只有量測延遲與可用性後，才考慮為特定事件增加線上查詢。

• 故障時預設放行還是阻擋？ 沒有統一答案。低金額、已知客戶可在規則備援下放行；關鍵特徵不可用

時，高金額新裝置付款可以加強驗證或阻擋。

• 隱私邊界是什麼？ 保留期限、跨區域處理、調查權限和特徵是否合法，需要安全、隱私與法遵負責人

確認。本答案最小化識別碼並稽核存取，但不虛構特定司法管轄區規則。

30 秒回答框架

「我會先固定帶版本的決策契約：一個 decision_id、不可變請求摘要、四類動作、100 毫秒 p99 預算 和人工審查硬上限。同步服務批次讀取新鮮線上特徵，用冪等的實體速率狀態把目前嘗試計入視窗，再執行硬 規則和模型，最後套用策略，並在回傳前持久化全部來源資訊。事件同時進入串流處理和離線儲存；訓練使用 時間點特徵和帶版本的成熟標籤。全域圖計算維持非同步，只發布精簡風險特徵。相依服務缺失或過期時，依 金額與身分風險執行明確的降級矩陣，不能悄悄給零分。最後用歷史影子重播、小流量發布、熱點鍵壓力和 故障注入，同時驗證詐欺結果與正常使用者摩擦。」

分步深入分析

第一步：把題目轉成預算和不變量

平均每秒 1,000 個請求代表每天 8,640 萬次決策。按每個請求 1.5 KB 計算，複寫和索引前每天約有 129.6 GB 原始輸入；尖峰每秒 5,000 個請求約為 7.5 MB/s。如果一筆精簡決策紀錄平均為 2 KB，七天 熱資料在索引和副本前約為 1.21 TB。這些只是容量錨點，不是精確儲存預測；壓縮率、欄位負擔和索引都要 實測。

更尖銳的產品約束是人工審查容量：每天 10,000 個案件只涵蓋 8,640 萬次決策的約 0.012%。策略必須 具備優先順序和准入控制。佇列滿時，最低優先審查區間要依預期損失與使用者摩擦轉為帶護欄的 ALLOW、 STEP_UP 或 BLOCK，不能無限堆積案件。

審查配額保存在決策服務的權威資料庫中。按日的條件計數器可再為不同風險區間保留名額，並在建立決策與 審查案件的同一個交易裡依 decision_id 認領。審查流量很低，不值得再引入獨立的分散式配額系統。認領 失敗時，策略先計算已聲明的溢出動作再提交，因此並發服務不會突破每日上限。

一個示例的 100 毫秒預算可以是：驗證與檢查 8 毫秒、批次線上特徵與速率狀態 25 毫秒、規則 10 毫秒、 模型推論 20 毫秒、策略與持久化決策 15 毫秒，剩餘 22 毫秒留給網路和長尾。每一段逾時都短於自己的 預算。關鍵不變量為：

one decision_id identifies one immutable request digest
an idempotent retry returns the original decision and does not increment velocity twice
every returned action has a persisted policy, model, rule, and feature provenance record
missing or expired critical features cannot be interpreted as normal values
review admissions never exceed the configured operational capacity
training features contain only values available at the historical decision time
labels retain source, observation time, maturity state, and version
raw payment card data never enters the fraud platform

第二步：定義 API 與決策紀錄

同步介面保持精簡：

POST /v1/risk/decisions              create or replay a decision
GET  /v1/risk/decisions/{decision_id} read the immutable result and current case status
POST /v1/reviews/{case_id}/disposition record an analyst outcome
POST /v1/feedback                     ingest a dispute or trusted fraud outcome

建立請求包含 decisionid、eventat、金額與幣別、代碼化實體 ID、商家與通路，以及本次請求屬性。 回應包含 action、穩定原因碼、選用的加強驗證類型或審查案件 ID，以及 decision_version。資料庫用 decision_id 唯一鍵保存正規化請求雜湊；同 ID、同雜湊重播原結果，同 ID、不同內容則回傳衝突。

依職責拆開資料：

• risk_decisions：識別碼、請求雜湊、事件時間、分數、動作、原因碼、特徵快照與新鮮度、規則包、模型

與策略版本、延遲和降級狀態；

• review_cases：決策參照、優先順序、佇列狀態、處理人、處置結論和時間戳記；
• feedback_labels：決策參照、標籤、來源、觀察時間、成熟狀態、信心和版本；
• policy_bundles：經過簽署且不可變的規則、門檻、審查預算和故障備援設定；
• outbox_events：本地已提交、等待非同步發布的決策事件。

回傳前，在一個本地交易中提交決策和 outbox。事件串流按至少一次投遞，消費者用 decision_id 與事件 版本去重。付款服務只能把這份不可變結果用於對應請求，不能更換金額或付款工具後繼續沿用。

第三步：拆開同步決策與學習管線

同步資料流為：

payment service
  -> decision API
  -> idempotency lookup
  -> batched online feature + velocity read
  -> hard rules
  -> model inference
  -> versioned action policy
  -> decision store + outbox
  -> ALLOW | STEP_UP | REVIEW | BLOCK

非同步資料流消費決策、身分驗證、付款結果、審查和拒付事件。串流處理器去重後依事件時間開窗，更新 十分鐘嘗試次數、一小時不同商家數、金額偏離、裝置年齡、近期驗證失敗等線上實體特徵。不可變原始事件 與特徵歷史也進入離線儲存，供分析與訓練使用。

這對應實用的特徵儲存分工：線上儲存保留最新值，服務低延遲讀取；離線儲存保留歷史時間序列，負責訓練 和物化。兩邊應共用特徵定義、型別、實體鍵和轉換測試，但不必共用儲存引擎。讓一個資料庫同時承擔任意 歷史掃描與穩定低延遲查詢，會把兩種衝突工作負載綁在一起。

規則和模型互補。硬性策略、可信封鎖清單與高信心速率限制明確且快速；模型負責組合較弱訊號和互動關係。 最終策略依規則結果、模型分數、特徵新鮮度、金額、身分可信度和審查容量映射動作。純模型方案在故障時 難以營運；純規則是合理的第一版，卻會隨行為變化逐漸僵化。

第四步：讓速率特徵恰好一次計入目前嘗試

由串流處理更新的計數可能落後於正在評分的請求。兩筆並發測卡請求可能讀到同一個舊計數。對少量關鍵 速率規則，使用分區風險狀態服務，提供冪等操作：

observe(entity_type, entity_id, window, decision_id, event_at, value)
  -> count, sum, distinct_estimate, state_version, freshness

服務依實體鍵排序更新，在視窗去重狀態中保存 decision_id，把目前嘗試計入後回傳新計數。重試會回傳 同一次觀察，不再重複加一。狀態分區具備副本和檢查點，也能從事件日誌重建。高基數去重特徵可使用有界 近似結構，精確阻擋門檻則使用精確計數。

一筆請求同時涉及帳戶、付款工具、裝置、IP 網段和商家。跨所有實體做全域原子交易會損害延遲與可用性。 平行查詢各實體，並分別保證冪等；若部分逾時，記錄哪組不可用並交給策略降級，絕不能用零替代缺失值。 還要單獨路由和壓測已知熱點實體，因為受攻擊的付款工具或 IP 可能讓單一分區過載，即使總 QPS 正常。

事件時間處理必須應付重複、遲到事件和閒置分區。浮水印描述事件時間進度，不會讓遲到資料自動消失。 為每項特徵定義允許遲到範圍，並以更高特徵版本發布修正，同時監控浮水印延遲。線上決策保留它實際看到 的快照；後續修正只改善未來決策與離線分析，不能假裝先前服務已經知道新值。

第五步：執行新鮮度契約和明確降級矩陣

每組特徵回傳 computed_at、來源事件時間、版本和最大允許年齡。特徵服務據此得到 FRESH、STALE、 MISSING 或 ERROR，策略直接使用這個狀態。只有業務上正常稀疏的資料才使用訓練過的缺失標記；相依 服務故障不能偽裝成普通空值交給模型。

使用具體故障矩陣：

具體欄位屬於業務決策，但必須有版本並接受測試。全部放行會把相依服務故障變成資損，全部阻擋會把它 變成客戶和營收故障。如果模型與關鍵速率狀態同時缺失，策略仍可利用金額、可信身分、商家風險和驗證 能力，但必須回傳獨立降級原因並通知值班人員。

第六步：建立時間點訓練集和可變標籤歷史

每筆歷史決策以自己的 decision_at 為邊界。只有底層事件已經發生，而且當時已經可用的特徵列才能參與。 時間點聯結必須處理遲到資料；用今天修正過的資料倉儲重算上個月七日計數，會洩漏當時線上服務沒有的資訊。

標籤有生命週期：

UNOBSERVED -> PROVISIONAL_ANALYST_OUTCOME -> MATURE_CONFIRMED_OUTCOME
                                      \-> CORRECTED_VERSION

具體成熟規則取決於付款和拒付流程。每個標籤版本都要保留，不能在之後拒付抵達時覆寫審查員結論。訓練 明確選擇一種標籤定義與成熟截止點。評估使用向前的時間切分，對重複或相互關聯案件做實體層級檢查，最後 保留一個完全未碰觸的時間窗。離線與線上特徵一致性測試要讓同一批原始事件經過兩套實作，再比較決策 邊界上的值。

監控不能只看整體 precision。需要衡量詐欺損失或避免損失、誤擋金額與比例、授權和加強驗證完成率、 審查命中率與佇列年齡、分數校準、特徵漂移、標籤涵蓋，並在合法前提下依商家、通路、地區、付款方式、 金額區間和身分狀態切片。全域表現良好的門檻仍可能悄悄傷害某個群體。

第七步：把圖偵測移出關鍵路徑

詐欺團伙會連結帳戶、裝置、付款工具、地址、商家和網路識別碼。每筆付款都遍歷完整圖，會與延遲和相依 服務預算衝突。串流與批次工作應預先計算危險鄰居數、共用裝置擴散度、連通分量風險、與已確認風險實體 的連結時間等精簡特徵，由線上儲存帶著新鮮度中繼資料提供最新版本。

這會產生已知偵測延遲。新攻擊活動出現時，營運人員可以先發布範圍收斂、帶簽署的規則或封鎖清單，等待 圖管線跟上。只有歷史重播證明線上圖查詢帶來顯著增量、p99 能放進剩餘預算，而且故障有明確備援時， 才值得加入同步路徑。圖證據還應向調查人員回傳可讀路徑或原因碼，不能只給無法解釋的分數。

第八步：發布、保護、觀測並驗證系統

規則、模型、特徵和策略門檻各有不可變版本，一份帶簽署策略包固定本次決策使用的組合。新版本先重播 帶成熟標籤的歷史流量，再用影子流量執行而不改變動作，之後進入小流量發布。晉級時比較詐欺損失、誤擋、 放行率、加強驗證完成率、審查准入與命中率、延遲、特徵新鮮度和備援率。回復只切換生效包指標，舊決策 仍可重現。

服務只接收代碼化 ID，對敏感屬性做傳輸與靜態加密，使用最小權限，稽核調查存取與策略變更，清理日誌， 並把策略核准和部署權限分開。資料刪除與保留工作依照已記錄的識別碼對應執行，並產出可稽核結果。訓練 匯出受存取控制，不能把審查備註或未來結果混入特徵。

驗證清單包括：

• 用相同和不同內容重播同一個 decision_id；
• 在浮水印邊界傳送重複、遲到和亂序事件；
• 比較歷史決策時間點的離線與線上特徵；
• 壓測每秒 5,000 個請求、熱點實體鍵和冷快取啟動；
• 分別關閉模型、線上儲存、串流處理器、一個狀態分區和審查系統；
• 耗盡審查容量並檢查准入策略；
• 影子執行並小流量發布一條故意更嚴格的規則，再執行回復；
• 測試特徵投毒、識別碼擴散、原因碼洩漏、未授權策略變更和重播濫用。

營運儀表板要分開系統健康與決策品質。系統指標包括端點延遲、錯誤、相依服務逾時、特徵年齡、串流延遲、 狀態重建進度、降級動作和佇列年齡；結果指標只在成熟標籤視窗上重算，並始終標記產生它們的策略與模型版本。

高品質示範回答

「我先固定決策契約：平均每秒評分 1,000 筆付款、尖峰 5,000 筆，p99 在 100 毫秒內回傳四種動作， 每天最多送審 10,000 個案件。這代表審查是稀缺動作，模型準確率不是唯一目標，策略還要權衡詐欺損失、 誤擋和加強驗證摩擦。

付款服務用穩定決策 ID、代碼化實體 ID、事件時間、金額和請求屬性呼叫決策介面。決策 ID 唯一保存不可 變請求雜湊：相同請求重播，內容變更則衝突。服務批次讀取帶版本的線上特徵，並把目前嘗試冪等寫入關鍵 實體的速率視窗，接著執行硬規則、一個模型和帶簽署的策略包。決策、原因碼、特徵新鮮度、命中規則、 模型與策略版本和 outbox 在動作回傳前提交。

事件串流更新線上彙總，並把原始歷史寫入離線儲存。訓練在原決策時間點聯結，只選擇在聲明截止點前成熟 的標籤版本。圖計算維持非同步，發布精簡的鄰居風險特徵。每組特徵都攜帶年齡與可用性；模型或關鍵計數 故障時，策略依金額與身分風險選擇規則備援、加強驗證、有限審查或阻擋，絕不能把故障當成零風險。

我會用歷史重播、影子流量和小流量逐步發布策略包，比較詐欺損失、誤擋、放行與加強驗證完成率、審查 命中率、延遲、特徵新鮮度和降級率，並依關鍵維度切片。重複請求與事件、遲到資料、熱點鍵、相依服務 故障、審查飽和和對抗性特徵輸入都要成為測試。這樣系統既滿足低延遲，也受營運容量約束，還能解釋並 重現每次決策。」

常見錯誤

• 錯誤：只最佳化 AUC 或準確率，再選一個門檻。 失敗原因：這些指標沒有包含損失金額、正常使用者

摩擦、審查容量與系統故障。修正方法：建立帶成本和容量約束的動作策略，同時監控結果與體驗指標。

• 錯誤：讀取串流更新計數，就假設已包含目前嘗試。 失敗原因：並發攻擊會讀到相同舊計數，重試還

可能重複計數。修正方法：對關鍵速率狀態依實體冪等觀察，並記錄狀態版本與新鮮度。

• 錯誤：相依服務不可用時填 NULL 或零。 失敗原因：故障被偽裝成普通低風險輸入。修正方法：把

可用性和年齡送入策略，執行經過測試的降級矩陣。

• 錯誤：同步查詢全域詐欺圖。 失敗原因：遍歷延遲不可預測，相依服務面也會破壞 SLO。修正方法：

非同步發布精簡圖特徵，任何線上查詢都要用量測到的增量價值證明。

• 錯誤：沒有拒付就立刻標成正常。 失敗原因：結果延遲，近期負樣本的觀察視窗不完整。修正方法：

保留標籤版本，只在聲明的成熟視窗訓練。

• 錯誤：用今天的資料倉儲重算歷史特徵。 失敗原因：遲到和修正資料會洩漏未來資訊。修正方法：用

事件時間與可用時間做時間點聯結，並保留實際服務快照。

• 錯誤：所有不確定案件都送人工。 失敗原因：每天 10,000 個名額只能涵蓋約 0.012% 的流量。修正

方法：依預期可避免損失排序，執行准入與溢出策略。

• 錯誤：規則或模型直接全量發布。 失敗原因：服務技術上可用，仍可能造成大面積誤擋。修正方法：

歷史重播、影子評估、小流量、簽署版本和快速回復。

追問及應對

追問一：同一付款工具的兩次並發嘗試都看到計數未達門檻，怎麼辦？

把關鍵規則從被動快取彙總改成依實體冪等觀察。狀態分區依該付款工具排序更新，每個決策 ID 只記錄一次， 把目前嘗試計入後回傳新計數與版本。其他實體特徵可以維持最終一致。壓測必須加入單一熱點付款工具，因為 均勻 QPS 測試暴露不了這個分區瓶頸。

追問二：模型服務故障十五分鐘，放行還是阻擋？

執行帶版本的故障矩陣。硬封鎖清單和關鍵速率規則繼續運作；低金額且身分可信的付款可由純規則放行， 高金額或新裝置付款可以加強驗證、進入有限審查佇列或阻擋。所有備援動作帶降級原因。既要監控相依服務 恢復，也要監控業務影響，不能悄悄回傳預設分數。

追問三：拒付標籤要幾週才成熟，但今天出現新攻擊活動，如何適應？

用驗證失敗、審查結論、商家回報和共用實體聚集等領先訊號支援調查，但將它們與成熟標籤分開記錄來源。 透過影子和小流量發布範圍收斂、可撤銷的規則。只有所選標籤定義具備足夠成熟涵蓋後才重新訓練，否則 最新的「看似正常」樣本會讓評估產生偏差。

追問四：每天需要審查 50,000 個案件，容量仍是 10,000，怎麼辦？

依預期可避免損失、證據品質、金額和時效排序，為必須處理的群體保留容量，只接收前 10,000 個。其餘 區間依預先核准的加強驗證、放行或阻擋策略處理，並監控佇列年齡與人員吞吐。只把訊息塞進沒有可執行 服務水準的佇列，是把過載藏起來。

追問五：為什麼不讓線上特徵儲存同時成為唯一訓練資料來源？

線上儲存為低延遲讀取保留最新值，通常無法重建數百萬個歷史決策時間點所知的資訊。訓練需要時間序列 歷史、時間點聯結、回填和大型掃描。應讓線上與離線儲存共用定義並接受一致性測試，而非強迫一個引擎 承擔兩種衝突負載。

追問六：圖工作後來發現某個詐欺團伙，能否改寫先前的決策？

不能。保留原動作與當時的完整來源，新增一筆帶觀察時間的發現或標籤版本，執行允許的後續動作，更新 實體線上風險以影響未來決策，並把案件納入重播。改寫舊決策會抹去服務當時真正知道的資訊，破壞稽核 和模型評估。