在收銀台前，你輕觸卡片，一個微小的旋轉圖標出現不到半秒，然後顯示“批准”或“拒絕”。在這短短的時間內，系統必須決定這筆交易是否看起來像你本人所為，還是像六個月前數據泄露中竊取你卡號的人。它需要了解你的消費模式、每日限額，甚至你是否允許跨國交易，並且必須在你不察覺的瞬間完成這一切。這正是 Databricks 博客文章所探討的內容：當你基於 Databricks 構建這樣的系統時，它是什麼樣的。
文章介紹了一個名為 retail-app 的示例應用（基於 FastAPI 後端和 React 前端，部署為 Databricks App），該應用將兩個平台能力結合在一起：具有路由優化的 Model Serving，以及 Lakebase（一個託管 Postgres 服務，用於存儲模型預測所需的檔案和特徵數據）。完整的代碼庫可在 GitHub 上獲取，你可以將其部署到自己的工作空間並親自體驗。
交易流程：模型首先對交易進行評分，然後應用檢查用户檔案規則。模型運行在前是因為無論結果如何都需要其延遲數據。隨後，檔案查找（每日消費上限、國際交易開關、居住國家）通過一系列 if 語句進行判斷。響應中包含了每一步的時間，讓你清楚看到毫秒都花在了哪裏。更新檔案（如改變每日限額、切換國際交易）是獨立操作，更改保存到數據庫後，下一次支付就會生效，無需重新部署或緩存失效。
路由優化是關鍵。當模型部署在 Databricks Model Serving 後端時，應用與推理容器之間存在網絡跳轉。對於批處理負載，幾毫秒的延遲無關緊要，但對於結賬體驗則至關重要。路由優化縮短了網絡路徑，啓用後，模型推理請求的通信更直接、更快速，從而提高每秒查詢數（QPS）並降低延遲。在示例應用中，端點名為 fraud-detection-lakebase，通過數據平面路徑使用 OAuth 進行查詢，而非個人訪問令牌。
Lakebase 作為模型所需數據的 Postgres 存儲。欺詐模型不僅看交易本身，還通過信用卡前六位（BIN）查詢客户歷史特徵（如平均交易金額、跨境比例、拒付率、過去 24 小時交易速度）。這些特徵存儲在名為 customer_features 的 Lakebase Postgres 表中。後端也讀取同一表獲取檔案數據。讀取時，後端從連接池借用一個連接，執行參數化 SELECT 查詢，並在 finally 塊中歸還連接。寫入時，用户通過 UI 更改每日限額或切換國際交易，後端根據允許編輯的列白名單構建動態 UPDATE 語句，只有白名單上的字段可寫入，且立即生效。
連接池和 OAuth 令牌輪換確保延遲穩定。每次交易至少訪問 Lakebase 兩次（模型特徵查找和後端檔案檢查），如果每次都新建連接，會增加 20-50 毫秒開銷。連接池保持少量連接就緒，多數請求可即取即用。由於 Lakebase 通過 OAuth 認證，應用使用服務主體憑據交換訪問令牌，並將客户端 ID 作為 Postgres 用户名、令牌作為密碼。令牌過期時，需重建連接池。示例代碼通過雙重檢查鎖定確保併發安全，並設置 30 秒定時器關閉舊池，讓正在進行的查詢完成。
模型容器內部也維護自己的 Lakebase 連接池，並在後台刷新令牌。模型返回 fraud_probability、fraud_flag 以及內部計時（lookup_ms、inference_ms、total_ms），後端將這些映射到前端顯示延遲瀑布圖。業務規則在模型評分後執行：比較交易金額與每日上限，以及檢查用户是否啓用國際交易。任一規則可覆蓋模型的批准，這意味着模型處理統計風險，而檔案處理用户偏好。
Lakebase 支持自動擴縮容和縮容至零。在生產環境中，Postgres 實例需要同時處理模型容器的特徵查找和後端的檔案讀取。基準測試顯示，穩定負載下單次查找時間在 p50 到 p75 為個位數毫秒，p95 的 13.9 毫秒跳變屬於正常波動，自動擴縮容可在其變得用户可見前吸收。啓用縮容至零後，無交易時即停止計費。
總體延遲分解如下：model_call_ms 為整個服務調用的牆鍾時間，model_lookup_ms 和 model_inference_ms 為模型容器內部分解，business_logic_ms 為檔案讀取和規則評估。前後端測量的總延遲差異即網絡開銷和框架開銷。在 UI 中，用户可看到模型推理、特徵查找和業務邏輯的延遲，直觀瞭解路由優化的效果。
總之，這個示例應用展示瞭如何通過路由優化、Lakebase 自動擴縮容、連接池和 OAuth 令牌輪換，在毫秒內完成實時欺詐檢測，同時保持高可用性和低成本。