Streaming Features for Real-Time AI, Freshness Has an SLA

Pull-quote: “A feature is not fresh because the pipeline is streaming. It is fresh because staleness is measured at the point of decision and someone is paged when it breaches.”

Why this matters

A real-time AI system is only as current as the context it reads at inference. When features lag, the model reasons about a world that no longer exists: the inventory that sold an hour ago, the flight that already departed, the price that moved. These failures masquerade as model problems, offline metrics look fine while live answers are wrong, and teams retrain when they should be measuring staleness. Every feature has a freshness SLA whether anyone declared it or not. The undeclared version is “whenever the batch job last ran,” and nobody signed off on that.

Freshness is bought, so buy it per feature

The cost curve across tiers is steep and nonlinear: always-on clusters, state stores, exactly-once plumbing, and the operational weight of pipelines that never sleep. Streaming everything is a budget decision disguised as an architecture decision. The negotiation is per feature: what does the decision lose per minute of staleness, and which tier does that justify? Flight delay cascades are a clean example, because a prediction’s operational value decays in minutes as the network state changes; that feature set earns streaming. A customer’s lifetime shipment count does not.

Measure staleness where the decision happens

Freshness claims about pipelines are beside the point; the number that matters is measured at the serving lookup: staleness equals serving time minus the event time of the newest record that contributed to the feature. Log it per inference, chart the distribution, and alert on SLA breach the way you would any SLO. Then decide the degraded behavior in advance, per feature: serve with a staleness disclosure, fall back to a conservative default, or refuse. “Silently serve stale” is the one option that should not exist. Skew is the second measurement: features computed offline for training and computed streaming for serving will drift apart unless training joins are point-in-time correct. Leakage in training and skew in serving are the same bug wearing two costumes. Anomaly detection raises the stakes further: a stale signal is a missed signal, because detection earns its keep precisely by arriving while the anomaly is still actionable.

The Databricks mechanics

Auto Loader handles incremental ingestion without hand-rolled file tracking. Lakeflow and DLT declare the streaming transformation with expectations attached, which puts the data contract inline with the stream, freshness clauses included. Delta feature tables serve the offline side for training; an online store serves the low-latency lookup at inference; watermarks keep event-time aggregation honest when events arrive late. One pipeline definition, promoted across environments, feeding both stores, is the shape that keeps training and serving from divorcing.

  events ──► Auto Loader ──► DLT / Structured Streaming
                              (expectations · watermarks)
                                       │
                              Delta feature table
                               │                │
                        offline store      online store
                        (training,         (inference
                         point-in-time      lookup, ms)
                         joins)                 │
                                  staleness = now − event_time
                                     │ within SLA → serve
                                     │ breach → disclose ·
                                     │          default · refuse

Closing

Declare a freshness SLA per feature, tier features by what staleness actually costs the decision, measure staleness at the serving lookup rather than trusting the pipeline’s self-description, keep training point-in-time correct so both sides of the model see the same world, and script the degraded behavior before the first breach. Real-time AI is not a faster pipeline. It is an explicit answer to one question, asked feature by feature: how old is too old, and what happens then?