Databricks Scales Real-Time Fraud Detection

The split-second decision at a checkout counter hinges on complex systems working in unison. Databricks has detailed how its platform, specifically combining Databricks Model Serving with route optimization and Databricks Lakebase Postgres, can score credit card transactions for fraud in under 50 milliseconds.

This real-time capability is crucial for user experience, preventing the noticeable lag that can disrupt a purchase. The system orchestrates model inference and business rule checks with precision.

The Transactional Milliseconds

A single transaction initiates a sequence: a machine learning model first scores the charge for potential fraud. Following this, the application verifies the user's profile against predefined business rules.

This order ensures that model latency is captured regardless of the final outcome, providing a complete performance picture.

Route Optimization for Speed

For interactive applications, minimizing network hops is paramount. Databricks Model Serving's route optimization feature shortens the path between the application and the inference container.

This optimization translates directly to lower latency and higher throughput, essential for high-volume transaction processing. It enables more direct communication, boosting queries per second.

The sample application utilizes the data-plane query path for this optimized inference, leveraging OAuth for secure authentication.

Lakebase: The Data Backbone

The fraud detection model relies on historical customer data, such as average transaction amounts and recent spending velocity. These features, stored in Databricks Lakebase Postgres, are accessed using the card's BIN number.

This same Lakebase table serves profile information, like daily spending limits and international transaction settings, to the application backend. This dual-reader approach consolidates data access.

Connection pooling within the application and model container is vital to avoid the overhead of establishing new database connections for every transaction. This pattern maintains a set of open connections, ready for immediate use.

OAuth and Token Rotation

Authenticating to Lakebase involves an OAuth flow, exchanging service principal credentials for access tokens. This eliminates the need for long-lived database passwords, enhancing security.

Managing expiring tokens within pooled connections requires careful handling. The system employs mechanisms to detect token changes and rebuild connection pools as needed, ensuring continuous operation.

This ensures that even as tokens rotate, the underlying connections remain valid and secure. The process is designed to prevent simultaneous pool rebuilds and allow in-flight queries to complete.

Model-Side Feature Lookups

Inside the model container, the MLflow pyfunc model performs its own Lakebase lookups. It extracts the card BIN, queries for customer features, and then runs inference using CatBoost.

Each step within the model is timed, providing granular insights into inference performance. These internal timings are passed back to the application for end-to-end visibility.

The model container maintains its own connection pool and handles background token refreshes, mirroring the backend's approach to data access. This ensures consistent performance during extended serving periods.

Business Rules Override

Post-inference, the application backend retrieves customer profile data from Lakebase. It then applies business rules, such as checking against daily spending limits or international transaction restrictions.

These rules can override a model's approval, prioritizing user-defined preferences. The time spent on these profile lookups and rule checks is measured and reported.

Autoscaling for Demand Fluctuations

The critical element for sustained performance under varying loads is autoscaling. Databricks Lakebase Postgres automatically adjusts compute resources within predefined minimum and maximum limits.

This ensures the database can handle peak demand without becoming a bottleneck, while also optimizing costs during off-peak hours. The system scales to zero when not in use, further reducing expenditure.