Databricks unifies feature logic—but live scoring still sees the latest available state

Databricks’ new fraud-detection walkthrough makes a useful distinction that applies well beyond fraud models: sharing one feature definition between training and production can prevent logic drift, but it cannot guarantee that every live decision observes an exact event-time snapshot.

One definition, two execution paths

In the Feature Views walkthrough, Databricks defines recent transaction counts, longer-term spending baselines and request-time comparisons once. Those definitions are used to build point-in-time training sets and to drive managed materialization for online inference.

That addresses two common model failures. Training-serving skew appears when the production feature is calculated differently from the feature used during training. Data leakage appears when a historical training row incorporates information that arrived after the decision being modeled. Databricks says Feature Views use each training example’s keys and timestamp to reconstruct the appropriate historical window.

The concrete design combines five- and ten-minute rolling features with a 30-day “Sawtooth” baseline. The longer window mixes batch-computed history with streaming updates, while a request-time feature compares the current payment with the customer’s stored average and standard deviation. Unity Catalog holds the definitions, permissions and lineage.

“Latest” is not the same as “as of this event”

The operational caveat is in the online path. The walkthrough says live lookup returns the latest available customer features; it does not select a historical snapshot using the event timestamp included in the request. Feature updates and scoring also run asynchronously, so another transaction may still be in flight when the next payment is evaluated.

Databricks’ demo avoids one self-contamination problem by scoring a payment before publishing it to Kafka. That keeps the current payment out of its own recent-history features and matches the training window, which excludes the event being predicted. But the ordering of nearby events still matters in production.

This means Feature Views solve definition consistency, not total-order consistency. Teams still need to decide what amount of feature lag is acceptable, how they will measure it and what the model should do when recent context is incomplete. The source also notes that a Sawtooth feature should wait two full days before production use, underscoring that materialization readiness is part of the contract.

What operators should verify

Before promoting a model, compare the historical cutoff rule with the live scoring sequence. Monitor materialization freshness separately from endpoint latency. Treat fallback values as explicit signals rather than ordinary observations; the walkthrough uses a separate indicator to distinguish missing history from a genuine zero.

The architecture is valuable because it removes a large class of duplicated pipeline logic. Its limit is equally important: one definition can keep calculations aligned, but it cannot make asynchronous data arrive synchronously.