Go Feature Server

Relevant source files

• CHANGELOG.md
• 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/charts/feast/Chart.yaml
• infra/charts/feast/README.md
• infra/charts/feast/charts/feature-server/Chart.yaml
• infra/charts/feast/charts/feature-server/README.md
• infra/charts/feast/charts/feature-server/values.yaml
• infra/charts/feast/charts/transformation-service/Chart.yaml
• infra/charts/feast/charts/transformation-service/README.md
• infra/charts/feast/charts/transformation-service/values.yaml
• infra/charts/feast/requirements.yaml
• infra/feast-operator/README.md
• infra/feast-operator/config/samples/kustomization.yaml
• infra/templates/README.md.jinja2
• java/pom.xml
• sdk/python/feast/infra/registry/contrib/hdfs/__init__.py
• sdk/python/feast/infra/registry/contrib/hdfs/hdfs_registry_store.py
• sdk/python/tests/unit/infra/registry/test_sql_registry.py

Purpose and Scope

The Go Feature Server is a high-performance implementation of Feast's online feature serving component, written in Go. It provides low-latency gRPC-based feature retrieval for real-time model inference workloads. The Go Feature Server is currently in alpha status and serves as a performance-focused alternative to the Python and Java feature servers.

This document covers the Go Feature Server's architecture, deployment patterns, configuration, and integration points within the Feast ecosystem. For information about other feature serving options, see:

• Python feature server: 4.1
• Java feature server: 4.3
• Offline feature server: docs/reference/feature-servers/offline-feature-server.md

System Architecture

The Go Feature Server operates as part of Feast's multi-language service layer, providing an optimized path for online feature retrieval in production environments.

Architecture Overview

Sources: docs/SUMMARY.md157 README.md230 CHANGELOG.md99-103

The Go Feature Server fits into Feast's overall architecture as shown below:

Multi-Language Feature Server Comparison

Sources: README.md226-230 docs/roadmap.md60-65 infra/charts/feast/README.md1-11

Key Features and Capabilities

The Go Feature Server provides the following core capabilities:

Feature	Status	Description
gRPC API	✅ Stable	High-performance feature retrieval via Protocol Buffers
Entity Serialization v3	✅ Supported	Compatible entity key generation with Python/Java servers
File Registry	✅ Supported	Local file-based registry for feature definitions
S3 Registry Store	✅ Supported	AWS S3-backed registry storage
GCS Registry Store	✅ Supported	Google Cloud Storage-backed registry storage
HDFS Registry Support	✅ Supported	Hadoop Distributed File System registry integration
OpenTelemetry	✅ Supported	Observability and distributed tracing
Transformation Service	✅ Supported	Integration with Python-based on-demand transformations
HTTP API	❌ Not Available	Only gRPC is supported (unlike Python server)

Sources: CHANGELOG.md25-135 docs/reference/registries/metadata.md1-29

Performance Characteristics

The Go Feature Server is optimized for:

• High throughput: Native Go concurrency model for handling concurrent requests
• Low latency: Minimal runtime overhead compared to Python/Java
• Memory efficiency: Efficient memory management for high-scale deployments
• gRPC-native: Protocol Buffers serialization without additional abstraction layers

Typical use cases include:

• Production inference services requiring <10ms feature retrieval latency
• High-traffic applications with thousands of concurrent requests
• Environments where Python's GIL or Java's GC would be bottlenecks
• Microservices architectures with gRPC as the standard communication protocol

Sources: README.md34 docs/getting-started/quickstart.md136

Deployment Patterns

Kubernetes Deployment via Feast Operator

The Go Feature Server can be deployed on Kubernetes using the Feast Operator. While the Python and Java feature servers have explicit helm chart support, the Go Feature Server deployment follows a similar pattern through the FeatureStore Custom Resource.

Kubernetes Deployment Architecture

Sources: infra/feast-operator/README.md1-143 docs/how-to-guides/feast-on-kubernetes.md1-72

Configuration Example

The Go Feature Server deployment is configured through the feature_store.yaml file, which includes a transformation service endpoint for on-demand feature support:

feature_store.yaml structure for Go Feature Server:

Configuration Key	Required	Description
project	Yes	Feast project name
registry.path	Yes	Registry URI (file://, s3://, gs://, hdfs://)
registry.cache_ttl_seconds	No	Registry cache refresh interval
online_store	Yes	Online store configuration
offline_store	Yes	Offline store configuration (for metadata)
entity_key_serialization_version	Recommended	Set to 3 for compatibility
feature_server.transformation_service_endpoint	Optional	Python transformation server endpoint

Example feature_store.yaml:

Sources: docs/reference/registries/metadata.md1-29 docs/getting-started/quickstart.md106-117

Docker Deployment

The Go Feature Server is available as a Docker image and can be deployed as a standalone container:

Docker Container Deployment

Sources: infra/charts/feast/charts/feature-server/values.yaml1-141 infra/charts/feast/README.md1-82

Registry Integration

The Go Feature Server supports multiple registry backend implementations for storing and retrieving feature definitions.

Registry Backend Options

Sources: CHANGELOG.md25-256 docs/reference/registries/hdfs.md1-42

Registry Store Implementations

Each registry store implementation provides the same interface for reading feature definitions:

Registry Type	Protocol	Path Format	Authentication
File	Local I/O	file:///path/to/registry.pb or relative path	File system permissions
S3	AWS SDK	s3://bucket-name/path/to/registry.pb	AWS credentials (IAM, env vars)
GCS	Google Cloud SDK	gs://bucket-name/path/to/registry.pb	GCP credentials (service account, env vars)
HDFS	Hadoop Client	hdfs://namenode:port/path/to/registry.pb	Hadoop config (HADOOP_HOME, Kerberos)

Registry Cache Behavior

The Go Feature Server maintains an in-memory cache of registry data to minimize latency:

1. Cache Population: On startup, the server reads the registry and loads all feature definitions
2. TTL Refresh: Based on registry.cache_ttl_seconds, the cache is periodically refreshed
3. Feature Resolution: When serving features, the server uses cached metadata to:
   • Resolve feature names to storage keys
   • Determine entity join keys
   • Identify required transformations

Sources: sdk/python/tests/unit/infra/registry/test_sql_registry.py1-59 docs/reference/registries/metadata.md12-13

gRPC API and Protocol

The Go Feature Server implements the Feast gRPC protocol for online feature retrieval. This protocol is defined in Protocol Buffer (.proto) files and is shared across all Feast feature server implementations.

gRPC Feature Retrieval Flow

Entity Key Serialization

The Go Feature Server implements Entity Key Serialization Version 3, which is the current standard for entity key generation in Feast:

• Entity Key Format: Serialized representation of entity values used as keys in the online store
• Version 3: Improved serialization that ensures consistency across Python, Java, and Go implementations
• Key Components: Entity name + entity values → deterministic hash → storage key

The serialization logic ensures that:

1. The same entity values produce identical keys across all feature servers
2. Keys are efficiently encoded for storage and retrieval
3. Multiple entity joins are properly handled

Sources: CHANGELOG.md49-135 infra/charts/feast/values.yaml46

GetOnlineFeatures Request

The primary gRPC endpoint accepts requests with:

• features: List of feature references (format: feature_view_name:feature_name)
• entities: Dictionary of entity values for which to retrieve features
• full_feature_names: Optional flag to return fully qualified feature names

GetOnlineFeatures Response

The response includes:

• field_values: Feature values for each entity, organized by feature name
• metadata: Timestamps, feature view information, and status codes
• statuses: Per-feature retrieval status (PRESENT, NOT_FOUND, NULL_VALUE)

Sources: docs/getting-started/quickstart.md136-164

Transformation Service Integration

The Go Feature Server can integrate with the Python-based Transformation Service for on-demand feature computations. This is necessary because on-demand transformations are typically defined in Python and cannot be executed natively in Go.

Transformation Service Integration Architecture

Configuration for Transformations

To enable on-demand feature transformation support in the Go Feature Server, configure the transformation service endpoint:

When deployed via Helm charts or the Feast Operator, the transformation service is automatically deployed alongside the Go Feature Server if on-demand feature views are defined.

Sources: infra/charts/feast/charts/transformation-service/README.md1-28 docs/reference/registries/metadata.md27-28 infra/charts/feast/charts/feature-server/values.yaml13-15

Transformation Flow

1. Request Reception: Go Feature Server receives GetOnlineFeatures request
2. ODFV Detection: Server checks if any requested features come from OnDemandFeatureViews
3. Base Feature Retrieval: Fetches underlying features from online store
4. Transformation Call: Sends base features + request features to transformation service via gRPC
5. Result Assembly: Receives transformed features and includes them in the response

Sources: infra/charts/feast/requirements.yaml1-15 infra/charts/feast/charts/transformation-service/Chart.yaml1-10

Observability and Monitoring

The Go Feature Server includes OpenTelemetry integration for distributed tracing and metrics collection.

OpenTelemetry Integration

The observability features include:

• Request tracing: End-to-end request flow tracking
• Performance metrics: Latency percentiles, throughput
• Error tracking: Error rates and failure modes
• Resource utilization: Memory and CPU usage patterns

Sources: CHANGELOG.md103

Comparison with Python and Java Feature Servers

Feature	Python Feature Server	Java Feature Server	Go Feature Server
Protocol	HTTP + gRPC	gRPC	gRPC only
Language	Python (FastAPI)	Java (Spring Boot)	Go
Performance	Moderate (GIL limits)	Good (JVM optimized)	Excellent (native, concurrent)
Memory	High (Python runtime)	High (JVM heap)	Low (native binary)
Startup Time	Fast	Slow (JVM warmup)	Very fast
ODFV Execution	Native	Via Python service	Via Python service
Deployment Size	Medium	Large (JVM + deps)	Small (single binary)
Ecosystem	Rich Python ML libs	Enterprise Java tools	Cloud-native Go tooling
Use Case	Development, prototyping	Enterprise JVM environments	High-performance production
Status	Stable	Alpha	Alpha
HTTP REST API	✅ Yes	✅ Yes	❌ No
Helm Charts	✅ Available	✅ Available	🔄 Via Operator

Sources: README.md226-232 docs/roadmap.md60-67 infra/charts/feast/README.md1-11

Configuration Reference

Environment Variables

The Go Feature Server respects standard Feast environment variables for configuration:

Environment Variable	Description	Example
FEAST_REPO_PATH	Path to feature repository	/etc/feast/
FEAST_PROJECT	Feast project name	my_project
AWS_ACCESS_KEY_ID	AWS credentials for S3 registry	(from AWS config)
AWS_SECRET_ACCESS_KEY	AWS secret key	(from AWS config)
GOOGLE_APPLICATION_CREDENTIALS	GCP service account file	/etc/gcp/sa.json
HADOOP_HOME	Hadoop installation directory (for HDFS)	/usr/local/hadoop

feature_store.yaml Options

Required minimal configuration:

Production configuration with remote stores:

Sources: docs/reference/registries/metadata.md1-29 docs/getting-started/quickstart.md106-117 docs/reference/registries/hdfs.md29-42

Deployment Best Practices

Kubernetes Deployment

When deploying via the Feast Operator, follow these patterns:

1. Resource Allocation: Configure appropriate CPU/memory limits based on traffic
2. Horizontal Scaling: Use Kubernetes HPA (Horizontal Pod Autoscaler) for traffic scaling
3. Health Checks: Implement liveness and readiness probes on the gRPC health endpoint
4. Service Mesh: Consider using Istio or Linkerd for additional observability and traffic management

Production Considerations

• Registry Choice: Use S3 or GCS registry for production (not local files)
• Cache TTL: Balance between registry freshness and load (60-300 seconds typical)
• Connection Pools: Online store connections should be pooled and reused
• Error Handling: Implement circuit breakers for online store failures
• Monitoring: Deploy OTEL collectors for centralized telemetry

Sources: docs/how-to-guides/running-feast-in-production.md1-240 docs/how-to-guides/feast-on-kubernetes.md1-72

Limitations and Future Work

Current limitations of the Go Feature Server (alpha status):

• HTTP API: No REST API support (gRPC only)
• Native ODFV: On-demand transformations require separate Python service
• Registry Types: SQL-based registry not yet supported
• Advanced Features: Some newer Feast features may lag Python implementation

The Go Feature Server is under active development with contributions from organizations like Expedia. Future enhancements may include native transformation support and additional registry backend options.

Sources: CHANGELOG.md99-135 docs/roadmap.md65