Recommendation serving needs more than regular feature lookup.

Why regular feature serving is not enough

A standard feature store is good at serving named values. Recommendation systems often need the history behind those values: what the user watched, skipped, searched, bought, dismissed, repeated, or just did in this session. They also need aggregates that are keyed by user, item, creator, category, device, locale, campaign, time window, and many other dimensions.

The practical problem is iteration speed. Each new ranking idea often needs a new stream job, a new Redis key family, a new offline materialization, and a new join in the online ranker. TemporalStore makes the fresh temporal state itself queryable: long sequences, filtered windows, latest state, and aggregate objects share one serving model.

Example: "why should we recommend this item now?"

A short-video or commerce recommender may need to know whether the user is currently in a high-intent session, whether the item is fresh, and whether similar items were skipped recently. Those facts are temporal. A flat feature vector hides the reason; TemporalStore can serve the sequence and aggregate evidence.

Request-time state:
  user recent sequence:
    searched "portable projector" 2 minutes ago
    viewed 5 projector items in 10 minutes
    skipped 3 refurbished items
    clicked creator_review_video_17

  user_category aggregate:
    category = electronics/projector
    view_count_30m = 12
    click_count_30m = 3
    skip_count_30m = 4
    last_positive_action = 2026-06-16T10:12:11Z

  item freshness aggregate:
    item_id = projector_9821
    click_rate_10m = 0.083
    conversion_rate_1h = 0.014
    inventory_state = available

Online state shape

TemporalStore can model recommendation state as typed temporal records rather than one large profile blob. The serving path can read bounded slices of recent behavior, filtered sequences, and pre-aggregated windows with strict limits.

RecommendationState:
  sequence:user:{user_id}:views
    fields = item_id, category_id, creator_id, dwell_ms, ts

  sequence:user:{user_id}:actions
    fields = item_id, action_type, session_id, device, ts

  aggregate:user_category:{user_id}:{category_id}:1h
    fields = view_count, click_count, dwell_sum, skip_count, last_ts

  aggregate:item:{item_id}:freshness
    fields = impressions_10m, clicks_10m, conversion_1h, quality_score, last_update_ts

How this maps to the latest TemporalStore code

The current C++ implementation already points at the right serving shape. A timestamped feature object stores rows ordered by timestamp and queries them with a start time, end time, and count limit. Temporal aggregates encode metric, dimensions, bucket width, and bucket id so rolling windows can be read through bounded range scans. The IPS-style path adds schema, slot, action type, data range, top-k, sort/filter operators, TTL, compaction, and quota controls for high-cardinality histories.

Serving pattern

At request time, the recommender can fetch the latest session sequence, filtered long behavior windows, and high-cardinality aggregates in one low-latency path. Offline jobs still matter for model training and heavy analysis, but the online ranker no longer needs a new cache or materialized service for every fresh temporal signal.

Why this is different

• Sequence features stay queryable online instead of being flattened too early.
• Aggregated features can be refreshed by event updates and read by window, key, and filter.
• High-cardinality dimensions are modeled as first-class serving keys, not ad hoc cache keys.
• Replay records can show exactly which behavior slice and aggregate window fed a ranker decision.
• LLM recommenders can use the same temporal signals to build smaller, fresher context packs.

Compared with other approaches