Skip to content

CONCEPT Cited by 1 source

Feature freshness

Definition

Feature freshness is the service-level property describing how recently a feature value in an online store reflects the underlying signal that produced it. If a user opens a document at T, a feature derived from "documents the user recently interacted with" should include that document as of some bounded interval T+Δ. The Δ is the freshness.

Stated in the Dropbox Dash feature-store post:

"Stale features can lower ranking quality and hurt user experience, so our feature store had to reflect new signals as soon as possible, often within minutes of user actions."

"Relevance also depends on speed and capturing user intent in real-time. If a user opens a document or joins a Slack channel, that signal should show up in their next search—within a few seconds." (Source: sources/2025-12-18-dropbox-feature-store-powering-real-time-ai-dash)

Why it's a first-class concern

Freshness is co-equal with latency in ranking-quality-driven systems:

  • Latency without freshness = fast answers based on stale signals → wrong ranking order.
  • Freshness without latency = correct ranking order, but retrieved too slowly for the user.
  • Both are required; the architecture has to hit both.

Unlike raw database replication lag, freshness isn't just "when did the last write land" — it's the end-to-end time from the event at the source system to the derived feature value being served, including:

  1. Event emission (a doc opens, a user joins a channel).
  2. Capture at source (CDC, event bus, log).
  3. Ingestion into the feature pipeline.
  4. Feature transformation.
  5. Write to the online store.
  6. Availability to the next read.

Each step has its own cost/latency trade-off — covered by the three lanes of patterns/hybrid-batch-streaming-ingestion.

Three ingestion lanes map to three freshness tiers

  1. Batch — minutes-to-hours, amenable to change detection; good for heavy joins/aggregations over historical windows.
  2. Streaming — seconds-to-minutes, near-real-time; good for collaboration/interaction signals that must surface "in their next search."
  3. Direct writes — seconds, for precomputed features produced by an adjacent pipeline (e.g. LLM evaluation scores) that skips batch entirely.

Not every feature needs the same freshness. "User opened doc X 2 seconds ago" is a streaming feature; "document embedding" can tolerate hours of staleness. A feature-store design that forces every feature onto the same ingestion path either over-invests in freshness (cost) or under-delivers on relevance.

Measurement

The Dropbox post doesn't quantify freshness numerically — it names "within minutes" as the bar for batch features and "within a few seconds" as the bar for real-time signals, and leaves the impact on ranking quality ("lower ranking quality") unquantified.

A rigorous freshness SLO tracks p50 / p95 / p99 of end-to-end delay for each feature, binned by source signal, and ties it to an offline-measured delta in ranking quality (NDCG or similar) as a function of staleness. This post doesn't disclose those numbers but is directionally consistent with the discipline.

Seen in

Last updated · 200 distilled / 1,178 read