Python Feature Server

Relevant source files

• CONTRIBUTING.md
• README.md
• docs/SUMMARY.md
• docs/getting-started/quickstart.md
• docs/getting-started/third-party-integrations.md
• docs/how-to-guides/feast-on-kubernetes.md
• docs/how-to-guides/running-feast-in-production.md
• docs/project/maintainers.md
• docs/reference/feature-servers/offline-feature-server.md
• docs/reference/registries/README.md
• docs/reference/registries/hdfs.md
• docs/reference/registries/metadata.md
• docs/roadmap.md
• examples/quickstart/quickstart.ipynb
• infra/feast-operator/README.md
• infra/feast-operator/config/samples/kustomization.yaml
• infra/templates/README.md.jinja2
• protos/feast/core/Registry.proto
• sdk/python/feast/errors.py
• sdk/python/feast/feature_store.py
• sdk/python/feast/infra/online_stores/milvus_online_store/milvus.py
• sdk/python/feast/infra/online_stores/online_store.py
• sdk/python/feast/infra/online_stores/sqlite.py
• sdk/python/feast/infra/passthrough_provider.py
• sdk/python/feast/infra/provider.py
• sdk/python/feast/infra/registry/contrib/hdfs/__init__.py
• sdk/python/feast/infra/registry/contrib/hdfs/hdfs_registry_store.py
• sdk/python/feast/repo_config.py
• sdk/python/feast/repo_operations.py
• sdk/python/tests/example_repos/example_feature_repo_1.py
• sdk/python/tests/foo_provider.py
• sdk/python/tests/integration/feature_repos/universal/online_store/milvus.py
• sdk/python/tests/unit/infra/registry/test_sql_registry.py
• sdk/python/tests/unit/online_store/test_online_retrieval.py

Purpose and Scope

The Python Feature Server is an HTTP and gRPC service wrapper around the FeatureStore class (sdk/python/feast/feature_store.py105-220) that exposes online feature retrieval capabilities through REST and RPC APIs. It is implemented using FastAPI for HTTP endpoints and supports gRPC for efficient binary communication. The server enables non-Python clients to retrieve features from the online store and provides a centralized, stateless service layer for production feature serving.

The feature server is imported and used via the feast.feature_server module (referenced in sdk/python/feast/feature_store.py46).

For information about:

• The Go-based high-performance feature server, see Go Feature Server
• The JVM-based feature server for enterprise environments, see Java Feature Server
• Using the FeatureStore Python SDK directly (embedded mode), see FeatureStore and Configuration
• The registry server for centralized metadata access, see docs/SUMMARY.md159
• Offline feature server for batch serving via Arrow Flight, see docs/reference/feature-servers/offline-feature-server.md

Architecture Overview

The Python Feature Server is a stateless service that wraps the FeatureStore class and exposes its methods via HTTP (FastAPI) and gRPC interfaces. Each request is delegated to a FeatureStore instance (sdk/python/feast/feature_store.py105-220), which uses the configured Provider (sdk/python/feast/infra/passthrough_provider.py58-90) and OnlineStore implementations to serve features.

System Context Diagram

Sources: sdk/python/feast/feature_store.py105-220 sdk/python/feast/feature_store.py46 sdk/python/feast/infra/passthrough_provider.py58-90 sdk/python/feast/infra/provider.py41-46

Request Flow for Online Feature Retrieval

Sources: sdk/python/feast/feature_store.py105-220 sdk/python/feast/infra/passthrough_provider.py239-258 sdk/python/feast/infra/provider.py283-320

Internal Component Architecture

Sources: sdk/python/feast/feature_store.py105-220 sdk/python/feast/repo_config.py253-317 sdk/python/feast/infra/passthrough_provider.py58-90

Configuration

The feature server is configured through the feature_store.yaml file. The RepoConfig class (sdk/python/feast/repo_config.py253-364) loads this configuration and provides it to the FeatureStore instance.

Feature Server Configuration

The feature_server field in feature_store.yaml is optional:

The configuration class is resolved via the FEATURE_SERVER_CONFIG_CLASS_FOR_TYPE dictionary (sdk/python/feast/repo_config.py109-112):

Type	Configuration Class
"local"	feast.infra.feature_servers.local_process.config.LocalFeatureServerConfig
"mcp"	feast.infra.mcp_servers.mcp_config.McpFeatureServerConfig

The RepoConfig validates and instantiates the appropriate configuration class via _validate_feature_server_config() (sdk/python/feast/repo_config.py557-580).

Key Configuration Fields

Field	Type	Description	Default
project	string	Project identifier	Required
registry	RegistryConfig	Registry configuration (file/SQL/remote)	Required
provider	string	Provider type (local, gcp, aws, azure)	"local"
online_store	OnlineStoreConfig	Online store configuration	sqlite
offline_store	OfflineStoreConfig	Offline store configuration	dask
auth	AuthConfig	Authentication configuration	no_auth
feature_server	FeatureServerConfig	Feature server-specific config	None

Sources: sdk/python/feast/repo_config.py253-364 sdk/python/feast/repo_config.py109-112 sdk/python/feast/repo_config.py557-580

Example Configurations

Local Development:

Production with SQL Registry:

Sources: docs/getting-started/quickstart.md106-118 sdk/python/feast/repo_config.py170-183

Starting the Feature Server

Using the Feast CLI

The feature server is started using the feast serve CLI command:

The command can be invoked with options:

The CLI command (sdk/python/feast/repo_operations.py414-429):

1. Calls create_feature_store() which loads feature_store.yaml via load_repo_config() (sdk/python/feast/repo_config.py170-183)
2. Initializes a FeatureStore instance (sdk/python/feast/feature_store.py124-169)
3. Passes the FeatureStore to the feast.feature_server module
4. Starts both HTTP (FastAPI on port 6566 by default) and gRPC servers

Sources: sdk/python/feast/repo_operations.py414-429 sdk/python/feast/feature_store.py124-169

Programmatic Initialization

While the feature server is typically started via CLI, you can initialize the underlying FeatureStore programmatically for testing:

The FeatureStore.__init__() method (sdk/python/feast/feature_store.py124-169):

• Accepts repo_path, config, or fs_yaml_file parameters
• Lazy-loads the registry and provider (only initialized when accessed)
• Uses property decorators for self.registry (sdk/python/feast/feature_store.py205-219) and self.provider (sdk/python/feast/feature_store.py250-254)

Sources: sdk/python/feast/feature_store.py124-169 sdk/python/feast/feature_store.py205-254

API Endpoints

HTTP REST API

The FastAPI-based HTTP interface provides REST endpoints for feature operations:

POST /get-online-features

Retrieves features from the online store for real-time inference. This endpoint wraps FeatureStore.get_online_features() (sdk/python/feast/feature_store.py1500-1652).

Request Format:

Response Format: The response is an OnlineResponse object serialized to JSON/Proto containing:

The OnlineResponse class encapsulates the feature values, statuses (PRESENT, NOT_FOUND, OUTSIDE_MAX_AGE), and event timestamps.

Sources: README.md137-164 sdk/python/feast/feature_store.py1500-1652

POST /push

Writes feature values directly to the online store for features backed by a PushSource. This endpoint wraps FeatureStore.push() or FeatureStore.write_to_online_store().

Request: Arrow table or DataFrame containing entity keys and feature values.

POST /materialize

Triggers materialization of features from the offline store to the online store. This endpoint wraps:

• FeatureStore.materialize() (sdk/python/feast/feature_store.py1900-2034) - Materialize features for a specific time range
• FeatureStore.materialize_incremental() (sdk/python/feast/feature_store.py2036-2133) - Materialize features since last materialization

Request:

Sources: sdk/python/feast/feature_store.py1900-2133

gRPC API

The gRPC interface uses Protocol Buffer definitions for efficient binary communication. The service is defined in feast/protos/feast/serving/ServingService.proto and implemented by the feature server.

GetOnlineFeatures RPC

Equivalent to the HTTP /get-online-features endpoint but uses Protocol Buffer messages for serialization. The same FeatureStore.get_online_features() method is called internally.

Message Types:

• Request: GetOnlineFeaturesRequest - contains feature references and entity values in proto format
• Response: GetOnlineFeaturesResponse (sdk/python/feast/protos/feast/serving/ServingService_pb2.py86-89) - contains FieldStatus and feature values as ValueProto

The response includes:

• field_values: Dict mapping feature names to ValueProto objects
• metadata: GetOnlineFeaturesMetadata with feature names
• results: List of GetOnlineFeaturesResponse.FeatureVector with statuses and timestamps

GetFeastServingInfo RPC

Returns metadata about the feature server instance:

• Feast version
• Supported capabilities (e.g., entity type support)
• Registry information

Sources: sdk/python/feast/protos/feast/serving/ServingService_pb2.py86-89 sdk/python/feast/feature_store.py1500-1652

Feature Retrieval Implementation

Online Feature Retrieval Path

The feature server delegates to FeatureStore.get_online_features() which orchestrates the retrieval:

Sources: sdk/python/feast/feature_store.py1500-1652 sdk/python/feast/infra/passthrough_provider.py239-258 sdk/python/feast/infra/online_stores/online_store.py1-30

Registry Caching

The FeatureStore caches registry metadata to reduce latency. The registry is lazy-loaded via the self.registry property (sdk/python/feast/feature_store.py205-219):

Cache Configuration:

The RegistryConfig class (sdk/python/feast/repo_config.py136-184) defines:

Field	Type	Description	Default
cache_ttl_seconds	int	TTL for in-memory cache (0 = never expire)	600
cache_mode	string	"sync" (immediate) or "thread" (background)	"sync"

Cache Behavior:

• sync mode: Registry refreshes immediately after writes via apply()
• thread mode: Background thread refreshes at cache_ttl_seconds intervals
• TTL=0: Cache never expires automatically (only via explicit refresh_registry())

Explicit Refresh: Call FeatureStore.refresh_registry() (sdk/python/feast/feature_store.py273-289):

This method also calls _clear_feature_service_cache() (sdk/python/feast/feature_store.py267-271) to invalidate cached feature service metadata.

Sources: sdk/python/feast/feature_store.py205-289 sdk/python/feast/repo_config.py136-184

Deployment Patterns

Local Development

For local development and testing, the feature server runs with SQLite online store:

Start the server:

Sources: docs/getting-started/quickstart.md106-118

Production Deployment on Kubernetes

Deployment Characteristics:

• Stateless pods enabling horizontal scaling
• Health check endpoints for liveness/readiness probes
• ConfigMap for feature_store.yaml configuration
• Secrets for sensitive credentials (database passwords, AWS keys, etc.)
• Service mesh integration for traffic management

Sources: docs/how-to-guides/running-feast-in-production.md1-27 infra/feast-operator/README.md1-19

Production Configuration Example

The registry_type: sql triggers SQL registry initialization via SqlRegistry (sdk/python/feast/infra/registry/sql.py). The path must follow SQLAlchemy connection string format. Note the validation in RegistryConfig.validate_path() (sdk/python/feast/repo_config.py170-183) that auto-corrects postgresql:// to postgresql+psycopg://.

Sources: sdk/python/feast/repo_config.py136-184 sdk/python/feast/repo_config.py170-183 docs/how-to-guides/running-feast-in-production.md33-49

Integration with FeatureStore Class

The feature server is a thin HTTP/gRPC wrapper around the FeatureStore class (sdk/python/feast/feature_store.py105-220). Each API request maps to a FeatureStore method call.

Request to Method Mapping

HTTP Endpoint	gRPC Method	FeatureStore Method	Line Reference
POST /get-online-features	GetOnlineFeatures	get_online_features()	sdk/python/feast/feature_store.py1500-1652
POST /push	-	push() or write_to_online_store()	sdk/python/feast/feature_store.py1690-1836
POST /materialize	-	materialize()	sdk/python/feast/feature_store.py1900-2034
POST /materialize-incremental	-	materialize_incremental()	sdk/python/feast/feature_store.py2036-2133

Key FeatureStore Methods

get_online_features() (sdk/python/feast/feature_store.py1500-1652):

materialize() (sdk/python/feast/feature_store.py1900-2034):

materialize_incremental() (sdk/python/feast/feature_store.py2036-2133):

Thread Safety

The feature server maintains a shared FeatureStore instance across requests:

• Registry: Lazy-loaded and cached with thread-safe access via property decorator
• Provider: Stateless PassthroughProvider delegates to online/offline stores
• Online Store: Implementations must handle concurrent reads (most do via connection pooling)
• Configuration: RepoConfig is immutable after initialization

The FeatureStore itself maintains minimal mutable state - the _feature_service_cache dict (sdk/python/feast/feature_store.py122) which is cleared on registry refresh.

Sources: sdk/python/feast/feature_store.py105-220 sdk/python/feast/feature_store.py1500-2133 sdk/python/feast/infra/passthrough_provider.py58-90

Comparison with Direct SDK Usage

Aspect	Python Feature Server	Direct SDK Usage
Language Support	Any language (HTTP/gRPC)	Python only
Deployment	Centralized service	Embedded in application
Latency	+1-2ms network overhead	Lowest latency
Scaling	Horizontal scaling	Scales with application
Registry Caching	Shared across requests	Per-application instance
Configuration	Centralized via service	Per-application config
Use Case	Microservices, polyglot environments	Python-based ML services

Sources: docs/getting-started/quickstart.md38 sdk/python/feast/feature_store.py104-223

Performance Considerations

Registry Cache Management

The registry cache significantly impacts latency. Key considerations:

• TTL Setting: Balance between latency and staleness

  • Low TTL (60-300s): Fresh metadata, higher registry load
  • High TTL (600-1800s): Lower load, potential staleness
  • TTL=0: Cache never expires (manual refresh required)

• Cache Mode:

  • "sync": Immediate consistency, higher latency on writes
  • "thread": Lower latency, eventual consistency

Sources: sdk/python/feast/feature_store.py208-223 sdk/python/feast/repo_config.py136-161

Online Store Selection

Different online stores have different latency profiles:

• SQLite: 1-10ms (local), not distributed
• Redis: 1-5ms, scales horizontally
• DynamoDB: 5-20ms, fully managed
• Bigtable: 5-10ms, high throughput

Sources: sdk/python/feast/repo_config.py68-89

Security Considerations

Authentication

The feature server can be configured with different authentication mechanisms:

• No Authentication (no_auth): Default, no authentication
• Kubernetes (kubernetes): Service account token validation
• OIDC (oidc): OAuth 2.0 / OpenID Connect integration

Configuration example:

Sources: sdk/python/feast/repo_config.py114-122 sdk/python/feast/repo_config.py221-223

Network Security

• Deploy behind API gateway or service mesh
• Use TLS for encryption in transit
• Network policies to restrict access to online store

Sources: docs/how-to-guides/running-feast-in-production.md1-27

Monitoring and Observability

Key Metrics

Monitor these metrics for production deployments:

• Request Latency: P50, P95, P99 for get_online_features() calls
• Request Rate: Requests per second
• Error Rate: Failed requests (4xx, 5xx)
• Registry Cache Hit Rate: Efficiency of registry caching
• Online Store Latency: Time spent in online store operations

Logging

The feature server logs key events:

• Feature retrieval requests
• Registry refresh operations
• Online store errors
• Configuration changes

Sources: sdk/python/feast/feature_store.py1-102

Troubleshooting

Common Issues

High Latency:

• Check online store latency and connection pool settings
• Verify registry cache TTL is not too low
• Ensure network connectivity is optimal

Feature Not Found Errors:

• Verify feast apply was run to register features
• Check registry cache TTL and refresh
• Confirm feature view names match request

Authentication Failures:

• Verify auth configuration matches client settings
• Check OIDC token validity and expiration
• Ensure service accounts have proper permissions

Sources: sdk/python/feast/errors.py17-70 sdk/python/feast/feature_store.py208-223