Introduction: The "Plumbing" Problem in ML

What is a Feature?

Think of building a model that predicts whether a credit card transaction is fraudulent. The raw data is a stream of transactions: timestamps, amounts, merchant names, and user IDs. None of that raw data goes directly into the model. Instead, you engineer features — derived signals that capture meaningful patterns. A Feature is a specific, computed piece of data that helps a model make a prediction.

• Raw Data: A transaction log: User 123 spent $50 at 10:00 AM.
• Feature: number_of_transactions_last_10_minutes (computed by counting rows in a time window).

The transformation from raw data to feature is where most of the engineering work in ML lives. It is also where most of the production failures originate.

The Chaos Without a Feature Store

Without a centralized system, the ML workflow fractures into two disconnected pipelines:

1. Training Pipeline: A data scientist writes a Pandas query in a Jupyter notebook to compute number_of_transactions_last_10_minutes for a historical dataset. The model trains on this data and achieves 95% accuracy.
2. Serving Pipeline: An ML engineer rewrites that same logic in Java for the production API. The "10 minutes" window is computed slightly differently — perhaps using server time instead of event time, or rounding to the nearest minute instead of using a rolling window.

The model now sees different data in production than it was trained on. Its accuracy degrades silently. This is the core problem.

A Feature Store (like Feast, Tecton, or Hopsworks) is a centralized system that manages the definition, storage, computation, and serving of features. It ensures that the feature logic is written once and executed consistently for both training and real-time inference. The data scientist and the ML engineer both call the same API — they get mathematically identical results.