Feature Stores
Beginner 12 min read Feature Stores

Feature Stores

One recipe for features, cooked twice: training and live

A feature store is the shared system where features are defined once, computed, versioned and served consistently to both training and live inference — eliminating the train/serve split-personality problem.

feature storeoffline featuresonline featuresfeature engineeringtraining serving skew
Prerequisites: Dataset Versioning
Before we start

What you will learn

  • Explain the problem a feature store solves
  • Distinguish offline (training) from online (serving) feature paths
  • Locate feature stores in the MLOps lifecycle
Introduction

What is this?

A feature store is a platform that centralizes feature definitions and values: features are defined once, computed in batch (offline) for training data and in real time (online) for inference, served through two consistent APIs. Both paths share the same source of truth and transformation logic, which is the core defense against training-serving skew.

Motivation

Why do you need it?

  • Teams reinvent feature code per model, then those copies drift apart.
  • Live models need the same numeric value the model trained on — a mismatch quietly destroys accuracy.
  • Shared, reusable features cut data-engineering duplicate to a fraction.
  • Freshness is handled by design: batch for training windows, online for real-time requests.
Think about it

Mental model

Imagine

One kitchen baking for both a wedding hall and a food truck

Think of

A feature store's two kitchens

The banquet kitchen (offline) bakes for events ahead of time; the truck (online) heats fresh portions on demand. Same recipes, same ingredients — otherwise the truck food wouldn't taste like the tasting (training) dinner.

Mechanics

How it works

  • Features are declared as catalog entries: name, owner, transformation logic, freshness requirement.
  • Offline computation materializes historical feature values for training datasets.
  • Online computation computes/retrieves the latest feature value per entity at request time.
  • Both paths write to versioned stores — batch tables and a low-latency online store.
  • Consumers read features via SDK: training pulls historical data, serving pulls point-in-time values.

One feature definition feeding both training and live serving.

Feature definitions
Offline path
Online path
Training data
Live inference
Real world

In production

  • A recommendation platform defines 'user-avg-session-duration' once and reuses it across three models.
  • A fraud model trains on 90 days of features and serves from the same store's online endpoint.
  • A churn team adds a feature; the store backfills historical values so retraining has coherent windows.
Guidelines

Best practices

  • Make feature definitions code-reviewed and versioned like model code.
  • Record freshness requirements per feature and enforce them in SLAs.
  • Reuse features across models — the store's value grows with reuse.
  • Instrument both paths with timestamps so consistency is measurable.
Watch out

Common mistakes

  • Adopting a store but letting teams still define features locally — the sprawl persists.
  • Ignoring point-in-time correctness so training windows use future data.
  • Online/offline divergences unmeasured — the store ships the disease it was meant to cure.
  • No ownership metadata, so a broken core feature has nobody responsible.
When things break

Debugging tips

  • Model 'fine offline, broken live' — check feature values online vs training: same recipe, same scale?
  • Backfill missing? Query the feature store's history API for the window.
  • Latency spike at serving? Feature lookups fanning out per request; batch the retrievals.
Interviews

Interview checkpoint

Test yourself

Quick quiz

0/2
1

Which problem is a feature store specifically designed to prevent?

2

A feature store replaces the need for computing features at all.

Go deeper

Official documentation

Feast documentation
docs
Feature stores — ML wiki perspective
docs