13. Data Freshness

Data freshness measures how up-to-date the data used for inference is. Stale features lead to poor predictions — but making everything real-time is expensive. You must design for the right freshness for each feature.

Freshness Tiers

Tier	Freshness	Examples	Pipeline
Real-time	<1 second	Current session activity, GPS location, weather	Streaming
Near real-time	Seconds—minutes	Recent clicks, page views, cart updates	Micro-batch / streaming
Batch fresh	Hours—days	User demographics, 7-day purchase history	Batch (hourly/daily)
Static	Weeks—months	User signup date, product category	Batch (weekly)

Streaming Feature Updates

For real-time features, use stream processing to compute and update feature values as events arrive.

# Streaming feature computation (Kafka Streams)
Input stream: purchases (user_id, amount, timestamp, product_id)
Stream processor:
  - Per-user sliding window (7 days)
  - compute: avg_purchase_amount_7d
  - compute: purchase_count_7d
  - compute: days_since_last_purchase
  - Output to online feature store (Redis) + offline store (S3)

Feature update latency: ~100ms from event → feature stored

Micro-Batching

Micro-batching strikes a balance between freshness and cost. Instead of processing every event individually (expensive), collect events into small time or size windows.

# Micro-batch feature computation
Window: 10 seconds or 1000 events, whichever comes first
Within window:
  - Aggregate events per user
  - Update feature values
  - Write batch update to feature store

Trade-off: 10s staleness vs 10x fewer DB writes vs streaming

Versioned Datasets

For training, you must use consistent snapshots of data. Versioning ensures reproducibility.

# Dataset versioning strategy
Dataset version: 2026-06-15-v3
Contains:
  - All events up to 2026-06-14T23:59:59Z
  - Features computed as of event_time (point-in-time correct)
  - Labels assigned based on outcomes known as of 2026-06-15

Benefits:
  - Reproducible training runs ("train on v3, eval on v4")
  - Rollback capability (deploy model trained on v2 if v3 is buggy)
  - Audit trail for compliance

Handling Late-Arriving Data

In distributed systems, events can arrive hours or days late. Your system must handle this gracefully:

Ignore late data: Simple but lose accuracy.
Recompute features: Update feature store and retrain if significant.
Watermarks: In streaming systems, define a cutoff (e.g., "events more than 1 hour late are dropped").
Grace period: Accept late events within a configurable window; compute corrections.

Exercise: A ride-sharing app uses driver location features for pricing and ETA. Classify each feature into a freshness tier: a) driver's current GPS position, b) driver's rating (average of all rides), c) driver's acceptance rate (last 100 rides), d) rider's home address, e) current traffic conditions by area, f) event surge multiplier. For each, describe the pipeline that keeps it fresh.