Feature Store Architecture and Design Cheat Sheet

Updated 2026-05-18

Next Topic: Federated Learning Cheat Sheet

🧠Study flashcards on this topic93 cards · spaced repetition→

A feature store is a centralized data platform that manages the storage, computation, and serving of machine learning features across training and inference pipelines. It solves the critical challenge of training-serving consistency by ensuring features computed during model training match those used in production predictions. Feature stores distinguish between online stores (low-latency serving for real-time inference) and offline stores (batch retrieval for training), while addressing point-in-time correctness to prevent data leakage. Understanding architectural patterns—literal, physical, or virtual—alongside platform choices like Feast, Tecton, and Hopsworks determines whether your feature store enables true operational ML at scale or becomes another data engineering burden.

What This Cheat Sheet Covers

This topic spans 13 focused tables and 104 indexed concepts, 93 flashcards. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.

Table 1: Core Architecture PatternsTable 2: Training-Serving Consistency MechanismsTable 3: Platform ComparisonTable 4: Feature Transformation PatternsTable 5: Data Consistency and QualityTable 6: Storage Backend PatternsTable 7: Feature Serving and RetrievalTable 8: Feature Lineage and Metadata ManagementTable 9: Security, Access Control, and GovernanceTable 10: Monitoring, Observability, and SLOsTable 11: Integration Patterns and EcosystemTable 12: Cost Optimization StrategiesTable 13: Common Anti-Patterns and Pitfalls

Quick IndexSubscribe to unlock

A jump-to index of every table row in this cheat sheet.

Mind MapSubscribe to unlock

An interactive map of every table and concept in this topic.

Table 1: Core Architecture Patterns

Feature stores emerged to solve the fundamental disconnect between how data scientists build models and how production systems serve predictions. Three distinct architectural patterns have evolved, each making different trade-offs between centralization, latency, and operational overhead.

Pattern	Example	Description
Literal (Centralized) Feature Store	`features_df = fs.compute_and_store(` `features=['user_30d_purchases']` `)`	• Centralized storage that computes features via data pipelines and persists all values • data scientists retrieve precomputed features directly from the store
Physical (Data Layer) Feature Store	`fs.register_transformation(` `sql="SELECT user_id, SUM(amount)...",` `source=warehouse` `)`	• Acts as a metadata layer mapping feature definitions to existing data sources (data warehouse, lake) • features remain in original storage, store provides unified access API
Virtual (Orchestration) Feature Store	`fs.define_feature_view(` `source=kafka_topic,` `transformation=streaming_logic` `)`	• Orchestrates feature computation at query time using external engines (Spark, Flink) • no persistent feature storage, generates features on-demand from raw data
Online Store	`feature_vector = online_store.get(` `entity_id="user_123",` `features=["clicks_1h", "cart_count"]` `)`	• Low-latency key-value store (Redis, DynamoDB) serving features for real-time inference • optimized for sub-10ms point lookups by entity key
Offline Store	`training_df = offline_store.get_historical(` `entities=user_ids,` `timestamp_col="event_time",` `features=["30d_purchases"]` `)`	• Batch-oriented storage (S3, Delta Lake, data warehouse) for generating training datasets • supports point-in-time joins over large historical data volumes
Feature Registry	`fs.create_feature_group(` `name="user_aggregates",` `primary_key=["user_id"],` `event_time="timestamp"` `)`	• Centralized catalog storing feature metadata, schemas, lineage, and ownership • serves as the system of record for feature definitions across the organization
Feature View	`fv = fs.create_feature_view(` `name="fraud_features",` `entities=[transaction],` `features=["amt_30d", "velocity"]` `)`	• Logical grouping of related features for a specific ML use case • defines which features to retrieve together and how to join them to entity keys
Hybrid Architecture	`# Batch to offline, stream to online` `batch_pipeline → offline_store` `stream_pipeline → online_store` `sync_job: offline → online`	• Combines offline and online stores with materialization jobs syncing feature values from batch computations to the online store for serving • most common production pattern

Table 2: Training-Serving Consistency Mechanisms

Training-serving skew—when models see different feature values in training versus production—is the most common cause of silent model degradation. Feature stores address this through architectural guarantees that ensure identical feature computation logic across both training and serving paths.

Mechanism	Example	Description
Shared Feature Definitions	`@fs.feature` `def user_30d_purchases(df):` `return df.groupby("user_id")` `.sum("purchases").over(30d)`	• Single source of truth for feature logic used identically for offline training data generation and online serving • prevents divergence between training and production code

The rest of this section is part of the full cheat sheet

Table 3: Platform Comparison

Choosing the right feature store platform depends on whether you prioritize operational simplicity (managed services like Tecton), flexibility and control (open-source Feast), or deep integration with existing data infrastructure (Databricks, Snowflake, Hopsworks).

Platform	Example	Description
Feast (Open Source)	`feast apply # Deploy features` `festserve # Start serving` `fs = FeatureStore(repo_path=".")`	• Most widely adopted open-source feature store • provides feature registry, offline store (S3, BigQuery), and online store (Redis, DynamoDB) with Python SDK and registry-based configuration

The rest of this section is part of the full cheat sheet

Table 4: Feature Transformation Patterns

Feature transformations convert raw data into ML-ready features, but the where and when of computation—batch pipelines, streaming engines, or on-demand inference—determines latency, cost, and operational complexity.

Pattern	Example	Description
Batch Transformation	`@daily_schedule` `def compute_user_features(spark):` `df = spark.read.parquet(events)` `return df.groupBy("user").agg(...)`	• Scheduled jobs (Spark, Airflow) computing features over large historical datasets • writes results to offline store for training, optionally syncs to online store for serving

The rest of this section is part of the full cheat sheet

Table 1: Core Architecture Patterns

Pattern	Example	Description
Literal (Centralized) Feature Store	`features_df = fs.compute_and_store(` `features=['user_30d_purchases']` `)`	• Centralized storage that computes features via data pipelines and persists all values • data scientists retrieve precomputed features directly from the store
Physical (Data Layer) Feature Store	`fs.register_transformation(` `sql="SELECT user_id, SUM(amount)...",` `source=warehouse` `)`	• Acts as a metadata layer mapping feature definitions to existing data sources (data warehouse, lake) • features remain in original storage, store provides unified access API
Virtual (Orchestration) Feature Store	`fs.define_feature_view(` `source=kafka_topic,` `transformation=streaming_logic` `)`	• Orchestrates feature computation at query time using external engines (Spark, Flink) • no persistent feature storage, generates features on-demand from raw data
Online Store	`feature_vector = online_store.get(` `entity_id="user_123",` `features=["clicks_1h", "cart_count"]` `)`	• Low-latency key-value store (Redis, DynamoDB) serving features for real-time inference • optimized for sub-10ms point lookups by entity key
Offline Store	`training_df = offline_store.get_historical(` `entities=user_ids,` `timestamp_col="event_time",` `features=["30d_purchases"]` `)`	• Batch-oriented storage (S3, Delta Lake, data warehouse) for generating training datasets • supports point-in-time joins over large historical data volumes
Feature Registry	`fs.create_feature_group(` `name="user_aggregates",` `primary_key=["user_id"],` `event_time="timestamp"` `)`	• Centralized catalog storing feature metadata, schemas, lineage, and ownership • serves as the system of record for feature definitions across the organization
Feature View	`fv = fs.create_feature_view(` `name="fraud_features",` `entities=[transaction],` `features=["amt_30d", "velocity"]` `)`	• Logical grouping of related features for a specific ML use case • defines which features to retrieve together and how to join them to entity keys
Hybrid Architecture	`# Batch to offline, stream to online` `batch_pipeline → offline_store` `stream_pipeline → online_store` `sync_job: offline → online`	• Combines offline and online stores with materialization jobs syncing feature values from batch computations to the online store for serving • most common production pattern

Table 2: Training-Serving Consistency Mechanisms

Mechanism	Example	Description
Shared Feature Definitions	`@fs.feature` `def user_30d_purchases(df):` `return df.groupby("user_id")` `.sum("purchases").over(30d)`	• Single source of truth for feature logic used identically for offline training data generation and online serving • prevents divergence between training and production code

Table 3: Platform Comparison

Platform	Example	Description
Feast (Open Source)	`feast apply # Deploy features` `festserve # Start serving` `fs = FeatureStore(repo_path=".")`	• Most widely adopted open-source feature store • provides feature registry, offline store (S3, BigQuery), and online store (Redis, DynamoDB) with Python SDK and registry-based configuration

Table 4: Feature Transformation Patterns

Pattern	Example	Description
Batch Transformation	`@daily_schedule` `def compute_user_features(spark):` `df = spark.read.parquet(events)` `return df.groupBy("user").agg(...)`	• Scheduled jobs (Spark, Airflow) computing features over large historical datasets • writes results to offline store for training, optionally syncs to online store for serving