🗄️ Feature Stores: Scaling ML Past a Handful of Models

About this simulation

With one or two models, a data scientist can write a bespoke pipeline from raw data to training set and get away with it. Once an organization runs a dozen models, that pattern breaks: every team recomputes the same "days since last purchase" or "rolling average spend" feature in its own dialect, at its own schedule, with its own subtle bugs — and the version used to train a model often drifts from the version computed at serving time.

How it works

• Without a feature store — each data source is wired directly into every model's own pipeline. The number of independent feature computations grows with sources × models, and nothing guarantees the offline (training) and online (serving) copies match.
• With a feature store — each feature is computed once from raw sources and materialized into a shared store; models simply read from it, both offline for training and online for low-latency serving, so the same definition is used everywhere.
• The orange pulses on the hub→model spokes represent the online serving path; their speed reflects how often the store refreshes.
• Turning off the store re-wires every model straight to raw sources — watch the pipeline count and skew risk climb.

Controls

• Models in production — how many ML models the organization is running.
• Shared feature store — toggles between a centralized store and ad-hoc per-model pipelines.
• Highlight train/serve skew — colors mismatched pipelines red when there is no shared store.
• Online refresh rate — how frequently the store's online copy is refreshed from source data.

Did you know?

Uber's Michelangelo platform (2017) is widely credited with popularizing the term "feature store" after Uber found the same rider/driver features being recomputed, inconsistently, across dozens of independent ML pipelines.