Feature Store: The Contract Between Data and Models
Feature Store: A centralized system that computes, stores, and serves ML features consistently across training and inference. It establishes a contract: the same feature definition produces the same value regardless of whether accessed during model training or real-time prediction.
The Problem It Solves
Without a feature store, teams compute features independently. Team A calculates user_click_rate using 7 days of data; Team B uses 30 days. Training pipelines compute features from batch data; serving systems compute from real-time streams using different code paths. The model trains on one feature definition but serves with another. Accuracy drops 15-20% and debugging takes weeks because the discrepancy is invisible—both pipelines produce valid numbers, just different ones.
Core Components
Feature registry: Central catalog of feature definitions including transformation logic, data sources, and ownership. Engineers search and discover existing features before creating duplicates. Offline store: Historical feature values for training, typically in columnar formats (Parquet) on object storage. Supports point-in-time queries to prevent label leakage. Online store: Latest feature values for inference, typically key-value stores (Redis, DynamoDB) with sub-10ms reads. Materialization pipeline: Computes features from raw data and writes to both stores.
The Contract Guarantee
The feature store guarantees that get_feature(user_123, timestamp_X) returns identical values whether called during training data generation or production serving. This requires: identical transformation code, same data sources, and point-in-time correctness (no future data leaking into historical queries). Breaking this contract is the single most common cause of training-serving skew.
Key Insight: Feature stores are not primarily about sharing features between teams (though that helps). They are about guaranteeing consistency between training and serving—the foundation of reliable ML systems.