Real-Time Features in Ranking

The Latency of User Intent

Consider a user browsing an e-commerce platform:

• Yesterday: User browsed for Gardening Tools.
• 30 seconds ago: User clicked 3 Laptop Computer Reviews.

If your recommendation engine relies exclusively on Offline Batch Features computed overnight (e.g. Spark jobs running at 2 AM):

The system will continue recommending Gardening Tools for the next 24 hours, completely ignoring the user's immediate, active intent!

Real-Time Features ingest sub-second user signals into real-time scoring models, updating recommendations in under 100 milliseconds.

┌──────────────────────────┬──────────────────────────┐
│ 1. OFFLINE BATCH FEATURES│ 2. REAL-TIME STREAMING   │
├──────────────────────────┼──────────────────────────┤
│ Updated nightly (Spark). │ Updated in sub-seconds   │
│ Long-term history (30d   │ (Kafka + Flink + Redis). │
│ user purchase counts).   │ Immediate intent (clicks │
│ Low cost, static.        │ in last 5 minutes!).     │
└──────────────────────────┴──────────────────────────┘

Real-Time Feature Store Architecture

  USER INTERACTION EVENT (Click / Search / Add-to-Cart)
                     │
                     ▼
  [ APACHE KAFKA EVENT STREAM ]
                     │
                     ▼
  [ APACHE FLINK STREAM PROCESSING ] ──► Calculates Sliding Windows (Clicks in last 5 mins!)
                     │
                     ▼
  [ ONLINE FEATURE STORE (Redis / Feast / DynamoDB) ]  ──► Sub-5ms Read Latency!
                     │
                     ▼
  [ REAL-TIME RANKING MODEL (vLLM / Triton) ] ──► Fresh Dynamic Feed Recommendations!

Key Components

1. Event Bus (Apache Kafka / Kinesis): Ingests raw clickstream event logs at high throughput ($100k+$ events/sec).
2. Stream Processor (Apache Flink): Computes sliding window aggregations (COUNT(clicks) OVER LAST 5 MINS, MEAN(price_viewed) OVER LAST 15 MINS).
3. Online Feature Store (Redis / DynamoDB): Stores key-value feature vectors indexed by user_id or item_id, delivering sub-10ms read latency for real-time model scoring.

Real-Time Feature Examples

┌──────────────────────────┬──────────────────────────┐
│ USER REAL-TIME FEATURES  │ ITEM REAL-TIME FEATURES  │
├──────────────────────────┼──────────────────────────┤
│ - Clicks in last 5 mins. │ - Impressions in last    │
│ - Category affinity vector │ 10 mins.               │
│   shift in current session.│ - Real-time stock status │
│ - Time elapsed since     │ - Instantaneous CTR in   │
│   last purchase.         │ last 1 hour.             │
└──────────────────────────┴──────────────────────────┘

Point-in-Time Correctness (Preventing Data Leakage)

When training models on historical real-time features, you must maintain Point-in-Time Correctness:

  Timestamp t: User clicked Item A.
  Feature Store must recreate feature values EXACTLY as they existed at timestamp t!
  (If you leak features from timestamp t+1 hour into training, the model receives future signals!)

Modern Feature Stores (Feast, Hopsworks, Tecton) provide Time-Travel Joins to generate point-in-time correct training datasets automatically.

Say this out loud

Real Time Features capture sub second user interaction signals to update recommendation feeds dynamically. Event streams from Kafka are processed by Apache Flink using sliding time windows, writing updated features to an Online Feature Store like Redis for sub 10ms inference lookups. Feature stores use time travel joins to ensure point in time correctness during model training.

Followups to expect

1. What is Dual Storage in Feature Stores (Online vs Offline Store)? Online stores (Redis/DynamoDB) optimize for low-latency single key reads during inference. Offline stores (Parquet/Snowflake) optimize for high-throughput batch reads during model training.
2. How do you handle Feature Freshness SLA breaches? Design fallbacks where the real-time model gracefully degrades to using 1-hour or 24-hour batch features if the streaming Flink pipeline suffers processing delays.