Feature Store
A system that computes, stores and serves model input features consistently for both training and inference, eliminating training-serving skew.
The problem it solves is specific and expensive: training-serving skew, where a feature is computed one way in the training pipeline and slightly differently in the serving path. The model performs well offline and badly in production, and the cause is invisible in both codebases because each is correct on its own terms.
A feature store defines each feature once and serves it to both paths from the same definition.
The two halves have different requirements: an offline store holding history for training, optimised for large batch reads and point-in-time correctness — reconstructing what a feature's value was at the moment of a historical event, which is what prevents label leakage; and an online store serving the current value at low latency for inference.
The secondary benefits are organisational: discovery and reuse, so teams find existing features instead of recomputing them; shared lineage and ownership; and monitoring for feature drift, which is frequently the real cause of a model's performance degrading while the model itself is unchanged.
The honest caveat: a feature store is infrastructure with real operating cost, and it is justified by multiple models and multiple teams sharing features. For one model owned by one team, it is usually premature, and a shared library that both paths import achieves most of the benefit.