Skip to content
Feature Engineering & Stores

11.02 · Concept

Offline vs Online Features

Determine whether a feature should be computed offline, online, on demand, or through a hybrid batch-stream pipeline.

No video curated for this lesson yet

This lesson is written, ordered and part of the path - the video slot is the only thing still open. We are working through Everything Data lesson by lesson; 55 of 85 have their video so far.

The written notes below cover this idea in full - you lose nothing by reading instead of watching.

Feature placement is a trade-off between freshness, latency, reproducibility, cost and operational risk. Stable historical attributes usually belong offline, request-derived values can be computed on demand, freshness-sensitive state needs online serving, and features needing both point-in-time correctness and recent updates often fit a batch-stream design.

What this lesson answers

  • when should features be computed offline or online
  • how to choose on demand feature computation
  • when use hybrid batch stream feature pipeline

Notes

Offline features are computed ahead of time from historical data, usually in a warehouse or lakehouse, and stored for later training or batch scoring. They are a good fit when the value does not need to reflect the latest user or system activity, such as a customer’s lifetime spend as of yesterday, a merchant’s 30-day average order value, or a product category embedding refreshed nightly. Offline computation is typically cheaper, easier to backfill, easier to validate, and better aligned with model training because you can recreate feature values at a specific point in time.

Common questions

What is the difference between offline and online features?
Offline features are prepared before serving, usually from historical data, then reused for training, batch scoring or later lookup. Online features are available at prediction time from a serving store, cache or operational system. The key distinction is not where the code runs, but whether the value must reflect recent activity when the model is called.
When should a feature be computed on demand?
Compute a feature on demand when it is derived from inputs already present in the request and does not need to be stored separately. Examples include request normalisation, distances, or combinations of live request data with known attributes. The cost is that computation and any failure now sit directly on the serving path.
Why use a hybrid batch-stream feature pipeline?
Use a hybrid approach when a feature needs reliable historical reconstruction as well as recent updates. Batch computation gives a stable, auditable baseline that is easier to backfill and align with training. Streaming then adds the latest events so serving is not limited to yesterday’s view of the world.