What happens in the milliseconds after you tap pay

Summary

At checkout, fraud scoring must combine transaction inference with customer-specific rules while keeping latency low enough for an interactive payment. The retail-app sample pairs a FastAPI backend and React frontend in a Databricks App with Model Serving route optimization and Lakebase Postgres, where the model retrieves historical features and the backend reads profile controls. A transaction is scored first, then checked against daily spending, international-transaction, and country rules; pooled OAuth-authenticated connections and token-rotation handling avoid repeated handshakes and stale credentials. In the supplied benchmark, route-optimized calls reached 27.2 ms p50 and 37.3 ms p95 end-to-end, with feature lookup at 8.9 ms p50, CatBoost inference at 0.4 ms, and network overhead at 17.4 ms p50; actual performance varies by model.

Context

Interactive fraud scoring needs to evaluate a transaction against a model and customer profile rules quickly enough for checkout. The model also requires historical customer features, while profile changes must become visible to subsequent payments without redeployment, cache invalidation, or batch flushing.

Approach / What changed

The sample retail-app combines a FastAPI backend, React frontend, Databricks Model Serving with route optimization, and Lakebase Postgres. It uses pooled OAuth-authenticated connections in both the backend and model container, parameterized reads, allowlisted profile updates, CatBoost inference, and timing data passed through to a frontend latency waterfall.

Takeaways

• The benchmark reports 27.2 ms median and 37.3 ms p95 end-to-end latency for route-optimized model calls, including routing, Lakebase lookup, inference, and response handling.
• Feature lookup inside the model container measured 8.9 ms at p50 and 13.9 ms at p95, while CatBoost prediction on a 12-feature vector measured 0.4 ms at p50.
• OAuth token rotation can require rebuilding the connection pool; double-check locking prevents concurrent rebuilds, and a 30-second delay allows in-flight queries to finish before the old pool closes.

Related reading