Feature Store

One place where a feature is defined, computed, stored and served — so that the thing a model trains on and the thing it is served are produced by the same code. It is infrastructure that exists mainly to prevent one failure, and the failure is expensive enough that the infrastructure is worth it.

Two access patterns from one definition, which is what makes it more than a database. Training needs the value a feature had at a past moment, joined across millions of rows, and it must be the value as of that moment rather than today's — the point-in-time join, and getting it wrong leaks the future into the training set. Serving needs one row in single-digit milliseconds. An offline store and an online store, written by the same pipeline, is the shape that falls out.

The point-in-time requirement is the hard part and the one people underestimate. A naive join takes the current value of a feature for a historical label, so the model trains on information that did not exist when the label was produced, and its offline accuracy is inflated by exactly the amount of leakage. That inflation does not show up until serving, where the feature is genuinely unavailable — which is why a model that tested well and serves badly is the classic symptom.