How should feature freshness requirements be decided, and what does getting them wrong cost?
Show the full answer Hide the answer
How to decide
Per feature, from the decision it informs and how quickly it becomes wrong.
- Session context — what the user has viewed in this session — must be seconds fresh, because the whole point is reacting to current behaviour.
- Recent interaction counts over hours tolerate minutes of lag.
- Long-window aggregates — thirty-day purchase behaviour — tolerate a day, since one more day changes them marginally.
- Item and category attributes change rarely and tolerate hours.
Uniform freshness across all features is the mistake in both directions: computing long-window aggregates in streaming pays streaming's cost for data that changes negligibly, and computing session context in batch makes the feature useless.
What getting it wrong costs
Too fresh: streaming infrastructure, state management and operational burden for features that did not need it — and the correctness cost, since streaming aggregates over long windows are harder to make correct than the equivalent batch computation.
Too stale: the model receives a feature that no longer reflects reality, degrading quality silently. And worse, if the training data was computed with different freshness than serving, the model learned a relationship that does not hold in production — which is training/serving skew arriving through the freshness dimension rather than through the definition.
The property that must hold regardless
The feature must be computed the same way for training and serving. A feature store where the definition exists once and is executed by both paths is what enforces this — and freshness is part of the definition, not an implementation detail of each path.
If training uses a value computed at day granularity and serving uses one computed continuously, they are different features with the same name.
The measurement
Publish freshness per feature as an SLI, and alert when it degrades. A feature silently becoming staler — because its pipeline slowed, not failed — degrades model quality with no error anywhere, and nothing else detects it.