MLOPS & DEPLOYMENT · QUESTION 70
How do you manage feature freshness for online predictions?
On this page
Feature freshness is how current a model input is relative to the decision being made. I define freshness targets per feature, track event and update timestamps, and choose batch, streaming, or request-time computation accordingly. Stale values should have explicit fallback behavior and monitoring. Freshness alone is not enough: late, duplicated, or incorrectly joined events can still make a current value wrong.
LET'S MAKE IT SIMPLE
First, the idea in plain English
A model may need to know what happened recently, such as transactions in the last hour. If the feature store updates only once per day, that value may not reflect the user’s current state. The system needs to balance freshness, compute cost, and reliability, while making clear how old a value is.
A USEFUL COMPARISON
Picture it this way
A weather report is useful only if you know when it was measured. A forecast from yesterday can be accurate for yesterday and still be the wrong input for a decision now. Model features similarly need timestamps and an acceptable age.
FOLLOW THE JOURNEY
Track event time and update lag from source to prediction
Connect event arrival, feature aggregation, serving lookup, and stale-value policy.
This simplified visual highlights the main relationships. In practice, the exact design depends on the requirements; Silent stale use can create incorrect decisions.
Source events carry event timestamps, a processor updates feature values, online serving checks freshness, and stale values follow a defined fallback or alert path.
How to read this visual
This simplified visual highlights the main relationships. In practice, the exact design depends on the requirements; Silent stale use can create incorrect decisions.
UNDER THE HOOD
How it works, step by step
Set per-feature freshness
Define maximum acceptable age based on the decision.
Why it matters: Different signals change at different rates.
Process updates
Use batch, streaming, or on-demand computation with event timestamps.
Why it matters: Update mode controls lag and operational cost.
Check at prediction time
Read value and its update metadata before using it.
Why it matters: A present value may still be stale.
Handle stale values
Fallback, recompute, defer, or reject according to the feature contract.
Why it matters: Silent stale use can create incorrect decisions.
OUTSIDE THE TEXTBOOK
A practical example
A payment-risk model uses recent account activity. The online feature value stores the latest processed event time, and the service checks its age before inference. If the stream is delayed beyond policy, the system uses a validated fallback or routes for review rather than treating an old count as current.
GO A LITTLE DEEPER
Technical details that matter
- Measure processing lag from event time to feature availability, not only time since the last database write.
- Watermarks and late-event policies affect aggregate correctness and finalization.
- A fresh feature can still be wrong due to duplicate events, schema changes, or an incorrect entity key.
MAKE A GOOD CHOICE
When is this useful?
- Fraud, recommendations, and other decisions sensitive to recent activity.
- Online feature pipelines fed by event streams.
- Investigating prediction changes caused by delayed upstream sources.
If a feature changes slowly, scheduled batch updates may be more reliable and cost-effective than streaming.
WATCH OUT FOR
Common misunderstandings
- Using update time instead of event time to claim freshness.
- Applying one freshness threshold to every feature.
- Failing silently when an online feature source is delayed.
REAL-WORLD TRADE-OFFS
Limitations and failure cases
- Low-latency streaming adds infrastructure and state management.
- Late or reordered events can revise aggregates.
- Freshness checks cannot establish whether the feature is semantically correct.
WHAT TO REMEMBER
Key takeaways
- 1Define freshness by decision need and per-feature behavior.
- 2Track event timestamps and processing lag.
- 3Specify observable fallback behavior for stale values.
PRACTICE THE FOLLOW-UP
What might an interviewer ask next?
How is event time different from update time?
Event time is when the real-world event occurred; update time is when the system processed or stored it. Their difference measures pipeline lag.
Should stale features always block predictions?
No. The policy depends on risk: a validated fallback may work for low-impact cases, while critical decisions may defer or route to review.
SAY IT OUT LOUD
How to explain this in an interview
“I define how fresh each feature must be for the decision, then track event timestamps and the time it becomes available to serving. Batch, streaming, or on-demand computation can meet different needs. At inference I check age and apply an explicit fallback or alert when stale. Freshness monitoring should be paired with checks for duplicates and incorrect joins.”
Connect this question to the roadmap topic it supports.