Java Feature Server

Relevant source files

• CHANGELOG.md
• 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
• java/pom.xml
• protos/feast/core/Registry.proto
• sdk/python/feast/driver_test_data.py
• sdk/python/feast/errors.py
• sdk/python/feast/feature_store.py
• sdk/python/feast/infra/offline_stores/bigquery.py
• sdk/python/feast/infra/offline_stores/offline_store.py
• sdk/python/feast/infra/offline_stores/offline_utils.py
• sdk/python/feast/infra/offline_stores/redshift.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/utils/aws_utils.py
• sdk/python/feast/repo_config.py
• sdk/python/feast/repo_operations.py
• sdk/python/feast/utils.py
• sdk/python/tests/foo_provider.py

The Java Feature Server is a high-performance, JVM-based implementation of Feast's online feature serving service. It provides low-latency feature retrieval via gRPC API, reading pre-materialized features from online stores and optionally invoking the transformation service for on-demand feature computation.

This document covers the Java implementation specifically. For the Python-based feature server, see Python Feature Server. For on-demand feature transformations, see Transformation Server.

Purpose and Architecture

The Java Feature Server is a production-grade, JVM-based serving layer optimized for high-throughput, low-latency online feature retrieval. It is built on Spring Boot and provides gRPC endpoints for real-time model inference workloads.

System Context

Diagram: Java Feature Server in the Feast Architecture

The Java Feature Server acts as a stateless query layer that:

1. Receives GetOnlineFeaturesRequest via gRPC (feast.proto.serving.ServingService)
2. Reads FeatureView definitions from the Registry (cached in-memory)
3. Retrieves pre-materialized features from the Online Store using entity key serialization
4. Optionally invokes the Transformation Service for OnDemandFeatureView computation
5. Returns GetOnlineFeaturesResponse with feature vectors and field statuses

Sources: protos/feast/serving/ServingService.proto1-136 infra/charts/feast/README.md1-82 infra/charts/feast/charts/feature-server/README.md1-68

Spring Boot Architecture

The Java Feature Server is implemented as a Spring Boot application in the java/serving module. The architecture follows Spring Boot conventions with dependency injection and auto-configuration:

Diagram: Spring Boot Component Architecture

Key Spring Boot components:

• gRPC Server: Configured via io.grpc.Server, listens on port 6566
• ServingService Implementation: Extends ServingServiceGrpc.ServingServiceImplBase from generated protobuf code
• Registry Client: Caches FeatureView metadata from registry (configurable TTL via feast.registry.cache_ttl_seconds)
• Online Store Factory: Dynamically instantiates store implementations based on feast.stores[].type configuration
• Transformation Client: Optional gRPC client for calling the Python transformation service

The application configuration is loaded from application.yml (default) and can be overridden via application-override.yaml (ConfigMap) or application-secret.yaml (Secret) in Kubernetes deployments.

Sources: java/pom.xml30-34 infra/charts/feast/charts/feature-server/values.yaml18-32

Comparison with Python Feature Server

The Java and Python Feature Servers share the same gRPC API (ServingService.proto) but differ in implementation and deployment characteristics:

Aspect	Java Feature Server	Python Feature Server
Runtime	JVM (Java 11+)	CPython (3.10-3.12)
Framework	Spring Boot	FastAPI + uvicorn
Protocol	gRPC only	HTTP REST + gRPC
Performance	Higher throughput, lower latency (optimized for production)	Good performance, easier to extend
Transformation	Delegates to Python service via gRPC	Native support via Python UDFs
Online Stores	Redis, DynamoDB, SQLite, PostgreSQL, Cassandra, Bigtable	All stores supported natively
Configuration	application.yml (Spring Boot)	feature_store.yaml (FeatureStore config)
Deployment	Helm chart feast-charts/feature-server	Helm chart feast-charts/feature-server (Python variant) or standalone
Docker Image	quay.io/feastdev/feature-server-java:0.58.0	Built-in (Python SDK) or custom
Use Case	Production deployments requiring maximum performance	Development, rapid prototyping, custom extensions

When to Choose Java Feature Server:

• Production workloads with high QPS requirements
• Environments where JVM infrastructure is standard
• Need for lower latency and higher throughput
• Stable feature serving without frequent Python UDF changes

When to Choose Python Feature Server:

• Development and testing environments
• Custom transformation logic that changes frequently
• Integration with Python ML pipelines
• HTTP REST API requirement

The Java server achieves better performance through:

1. JVM JIT compilation and optimizations
2. Native gRPC implementation without Python GIL constraints
3. Efficient connection pooling and reactive programming (Reactor)
4. Lower memory overhead per request

Sources: java/pom.xml44-72 infra/charts/feast/README.md4-7 infra/charts/feast/charts/feature-server/values.yaml4-10

Maven Project Structure

The Java Feature Server is built as a multi-module Maven project under the java/ directory with the parent POM at java/pom.xml:

Diagram: Maven Module Structure

Module	Artifact ID	Directory	Description
Parent	feast-parent	java/	Root POM defining dependencies and build configuration
datatypes	feast-datatypes	java/datatypes/	Common data type definitions and protobuf-generated code
serving	feast-serving	java/serving/	Main feature server implementation with Spring Boot
serving-client	feast-serving-client	java/serving-client/	Java client library for calling the feature server
coverage	feast-coverage	java/coverage/	Aggregates test coverage across modules using JaCoCo

Build Configuration:

The parent POM defines:

• Java 11 as the compilation target (maven-compiler-plugin)
• gRPC 1.63.0 and Protocol Buffers 3.25.5 for service implementation
• Spring Boot dependencies (managed transitively)
• Google Java Format enforcement via spotless-maven-plugin
• JaCoCo for test coverage reporting

Modules are declared at java/pom.xml30-35 and inherit common configuration from the parent POM.

Sources: java/pom.xml18-35 java/pom.xml37-39 java/pom.xml324-342

gRPC Service Interface

The Java Feature Server implements the ServingService gRPC interface defined in Protocol Buffers.

Service Definition

Diagram: ServingService gRPC Methods

The service exposes two RPC methods:

RPC Method	Request Type	Response Type	Purpose
GetFeastServingInfo	GetFeastServingInfoRequest	GetFeastServingInfoResponse	Returns Feast version information
GetOnlineFeatures	GetOnlineFeaturesRequest	GetOnlineFeaturesResponse	Retrieves online features for given entities

Sources: protos/feast/serving/ServingService.proto28-33

GetOnlineFeatures Request Structure

The GetOnlineFeaturesRequest message (defined in protos/feast/serving/ServingService.proto) supports two modes of feature specification:

Diagram: GetOnlineFeaturesRequest Message Structure

Key fields defined at protos/feast/serving/ServingService.proto80-94:

• kind (oneof): Either a feature_service name (string) or a FeatureList containing feature references
  • When using feature_service: retrieves features defined in a FeatureService object
  • When using features: explicit list of features in format feature_view:feature_name
• entities: Map of entity name to RepeatedValue containing entity values in columnar format for batch retrieval
  • Example: {"driver_id": RepeatedValue([1001, 1002, 1003])}
  • Enables efficient batch feature retrieval for multiple entity keys in a single request
• request_context: Additional context values for on-demand feature transformations (OnDemandFeatureView)
  • Example: {"request_timestamp": RepeatedValue([...]), "user_location": RepeatedValue([...])}
• full_feature_names: Boolean flag to return features with fully qualified names (e.g., driver_stats:conv_rate instead of conv_rate)

Java Generated Class:

The protobuf compiler generates feast.proto.serving.ServingAPIProto.GetOnlineFeaturesRequest with builder pattern:

Sources: protos/feast/serving/ServingService.proto80-94 protos/feast/serving/ServingService.proto24-26

GetOnlineFeatures Response Structure

Diagram: GetOnlineFeaturesResponse Message Structure

The response structure at protos/feast/serving/ServingService.proto96-110:

• metadata: Contains feature_names (FeatureList) in the order features are returned
• results: Array of FeatureVector objects, one per feature, maintaining the same order as metadata
  • Length of results matches length of requested features
  • Preserves feature order from request
• status: Boolean indicating overall request success
• FeatureVector: Contains three parallel arrays with one element per entity:
  • values: Actual feature values (feast.types.Value)
  • statuses: Field status codes (FieldStatus enum)
  • event_timestamps: Timestamps when features were written to online store

Field Status Enum Values (defined at protos/feast/serving/ServingService.proto116-135):

Status	Code	Meaning	When Set
INVALID	0	Status is unset	Default/error condition
PRESENT	1	Feature value exists and is within max age	Normal case
NULL_VALUE	2	Entity exists but feature value is null	Null written to online store
NOT_FOUND	3	Entity key not found in online store	Entity not materialized or doesn't exist
OUTSIDE_MAX_AGE	4	Feature value exists but exceeds max age threshold	Feature is stale (timestamp too old)

Example Response Structure:

For a request with 3 entities and 2 features:

• metadata.feature_names = ["driver_stats:conv_rate", "driver_stats:avg_daily_trips"]
• results[0] (conv_rate): FeatureVector with 3 values, 3 statuses, 3 timestamps
• results[1] (avg_daily_trips): FeatureVector with 3 values, 3 statuses, 3 timestamps

Java Generated Class:

Sources: protos/feast/serving/ServingService.proto96-135

Feature Retrieval Flow

The Java Feature Server executes the following flow when handling a GetOnlineFeatures request:

Diagram: Feature Retrieval Sequence

The retrieval process:

1. Request Parsing: Determine which features to retrieve (from feature service or explicit list)
2. Metadata Lookup: Fetch feature view definitions from Registry (cached)
3. Entity Key Generation: Serialize entity values into storage keys
4. Batch Retrieval: Read all requested features from online store in batch
5. Staleness Check: Compare feature timestamps against max age configuration
6. On-Demand Transformation: If ODFVs are requested, call Transformation Service
7. Response Assembly: Construct response with values, statuses, and timestamps

Sources: protos/feast/serving/ServingService.proto80-110 infra/charts/feast/charts/feature-server/values.yaml13-16

Configuration and Deployment

Application Configuration

The Java Feature Server uses Spring Boot's configuration system with a layered approach for managing settings. Configuration files are merged in order of precedence:

Configuration Layer	File	Purpose	Precedence	Kubernetes Resource
Default	application.yaml	Base configuration bundled in JAR at java/serving/src/main/resources/application.yml	Lowest	N/A (built-in)
Generated	application-generated.yaml	Helm-generated config (registry path, project, global settings)	Medium	ConfigMap
Secret	application-secret.yaml	Sensitive configuration (passwords, API keys)	High	Secret
Override	application-override.yaml	User customizations for deployment-specific settings	Highest	ConfigMap

Configuration Merging:

Spring Boot merges these YAML files using property source ordering. Later sources override earlier ones. For example:

Key Configuration Properties:

Helm Chart Configuration:

In Kubernetes deployments, configuration layers are mounted as volumes:

• application.yaml: Embedded in Docker image
• application-generated.yaml: Generated by Helm from global.* values
• application-secret.yaml: Mounted from Kubernetes Secret (if enabled)
• application-override.yaml: Mounted from ConfigMap

Enable/disable layers via infra/charts/feast/charts/feature-server/values.yaml18-32:

Sources: infra/charts/feast/charts/feature-server/values.yaml18-32 infra/charts/feast/charts/feature-server/README.md14-17 infra/charts/feast/README.md33-54

Helm Chart Deployment

The Java Feature Server is deployed via Helm chart with the following structure:

Diagram: Helm Chart Structure

Installation:

Key Configuration Values:

Sources: infra/charts/feast/requirements.yaml1-15 infra/charts/feast/README.md14-58 infra/charts/feast/charts/feature-server/values.yaml1-141

Docker Image

The feature server is packaged as a Docker image: quay.io/feastdev/feature-server-java:0.58.0

Key runtime configuration:

Environment Variable	Purpose
JAVA_OPTS	JVM tuning parameters (e.g., -Xms2048m -Xmx2048m)
LOG_TYPE	Log format: JSON or Console
LOG_LEVEL	Logging level: DEBUG, INFO, WARN, ERROR

Sources: infra/charts/feast/charts/feature-server/values.yaml4-10 infra/charts/feast/charts/feature-server/values.yaml34-40

Online Store Integration

The Java Feature Server supports multiple online store backends through a pluggable store configuration:

Diagram: Online Store Backend Support

Configuration Example:

Entity Key Serialization

The feature server uses entity key serialization to generate storage keys for online store lookups:

Configuration:

Version	Format	Notes
1	Legacy format	Deprecated
2	Intermediate format	Deprecated
3	Current format	Default for new deployments

Entity keys are generated by serializing entity values according to the schema defined in feature views, then hashing to create a consistent storage key across online stores.

Sources: infra/charts/feast/README.md33-54 infra/charts/feast/charts/feature-server/values.yaml13-16

Service Endpoints and Probes

gRPC Service

The primary service endpoint is a gRPC server listening on port 6566:

Diagram: gRPC Endpoints

The service is exposed via Kubernetes Service:

Sources: infra/charts/feast/charts/feature-server/values.yaml71-81

Health Probes

The feature server implements Kubernetes liveness and readiness probes:

Probe Type	Initial Delay	Period	Timeout	Failure Threshold
Liveness	60s	10s	5s	5
Readiness	15s	10s	10s	5

Liveness Probe: Ensures the server process is running and responsive Readiness Probe: Verifies the server has loaded registry metadata and can serve requests

Sources: infra/charts/feast/charts/feature-server/values.yaml43-69

Transformation Service Integration

For on-demand feature transformations, the Java Feature Server delegates to the Python-based Transformation Service:

Diagram: Transformation Service Call Flow

Configuration:

The transformation service is optional. If not configured, requests for on-demand features will return an error.

Sources: infra/charts/feast/charts/feature-server/values.yaml13-16 infra/charts/feast/README.md6-7

Maven Build Configuration

Key Dependencies

The Java Feature Server uses the following core dependencies (managed in parent POM):

Dependency	Version	Purpose
gRPC	1.63.0	Service implementation
Protocol Buffers	3.25.5	Message serialization
Netty	4.1.96.Final	Network transport
Reactor	3.4.34	Reactive programming
Guava	32.0.0-jre	Utilities
Jackson	2.15.0	JSON processing

Sources: java/pom.xml44-72

Build Plugins

The Maven build includes:

• protobuf-maven-plugin: Compiles .proto files to Java classes
• maven-compiler-plugin: Java 11 compilation with Lombok and AutoValue annotation processing
• spotless-maven-plugin: Code formatting enforcement (Google Java Style)
• maven-surefire-plugin: Unit test execution
• maven-failsafe-plugin: Integration test execution

Sources: java/pom.xml258-582

Testing Configuration

Unit tests are executed with 2GB heap:

Sources: java/pom.xml96-97 java/pom.xml403-405

Implementation Details

Java Package Structure

The Java Feature Server uses protobuf-generated code in the feast.proto.* package namespace. The protobuf compiler (protoc) generates Java classes from .proto files in the protos/ directory.

Package Mapping:

Proto Package	Java Package	Generated Outer Class	Proto Files
feast.serving	feast.proto.serving	ServingAPIProto	protos/feast/serving/ServingService.proto
feast.types	feast.proto.types	ValueProto	protos/feast/types/Value.proto
feast.core	feast.proto.core	Various	protos/feast/core/*.proto

Configuration at protos/feast/serving/ServingService.proto24-26:

Key Generated Classes:

Java Class	Protobuf Message	Purpose
ServingAPIProto.GetOnlineFeaturesRequest	GetOnlineFeaturesRequest	Request message
ServingAPIProto.GetOnlineFeaturesResponse	GetOnlineFeaturesResponse	Response message
ServingAPIProto.FeatureVector	FeatureVector	Feature values for entities
ServingAPIProto.FieldStatus	FieldStatus (enum)	Feature availability status
ServingAPIProto.GetFeastServingInfoRequest	GetFeastServingInfoRequest	Version info request
ServingAPIProto.GetFeastServingInfoResponse	GetFeastServingInfoResponse	Version info response
ServingServiceGrpc	ServingService (service)	gRPC service stub and impl base

Maven Protobuf Plugin Configuration:

The protobuf-maven-plugin (configured in parent POM) compiles .proto files during the build:

Generated classes are output to target/generated-sources/protobuf/java/ and included in the build classpath.

Sources: protos/feast/serving/ServingService.proto24-26 java/pom.xml577-580

Entity Key Serialization

The Java Feature Server serializes entity values into storage keys for online store lookups. The serialization version is configurable via feast.entityKeySerializationVersion:

Diagram: Entity Key Serialization Process

Serialization Versions:

Version	Status	Format	Notes
1	Deprecated	Legacy format	Compatibility with old deployments
2	Deprecated	Intermediate format	Migration path from v1 to v3
3	Current	Optimized format	Default for new deployments, recommended

Configuration:

Serialization Algorithm (Version 3):

1. Retrieve entity schema from FeatureView (entity names and types from registry)
2. Sort entities by name (deterministic ordering)
3. For each entity:
   • Serialize value according to its type (ValueType enum)
   • Apply consistent hashing algorithm
4. Combine serialized values into final storage key
5. Use key for online store read/write operations

The serialization ensures:

• Consistency: Same entity values always produce same key
• Uniqueness: Different entity values produce different keys
• Compatibility: Keys are portable across online store implementations

Example:

Sources: infra/charts/feast/README.md46 CHANGELOG.md101

Ingress and TLS Configuration

The Helm chart supports exposing the gRPC service via Kubernetes Ingress:

TLS Configuration:

For production deployments, it is recommended to:

1. Enable HTTPS with valid TLS certificates
2. Configure ingress authentication
3. Set IP whitelisting for security

Sources: infra/charts/feast/charts/feature-server/values.yaml82-123

Resource Configuration

Resource requests and limits can be configured for production workloads:

JVM Heap Configuration:

It is important to set heap limits explicitly to avoid JVM using more memory than the Kubernetes limit, which would cause OOMKilled errors.

Sources: infra/charts/feast/charts/feature-server/values.yaml34-36 infra/charts/feast/charts/feature-server/values.yaml124-125

Observability and Monitoring

Logging Configuration

Console Format: Human-readable, suitable for development JSON Format: Structured logging for production, integrates with log aggregation systems

Metrics

The Java Feature Server can expose Prometheus metrics for monitoring (configuration depends on application.yml settings):

• Request rates
• Latency percentiles
• Online store read latency
• Feature retrieval success/failure rates
• Registry cache hit rates

Sources: infra/charts/feast/charts/feature-server/values.yaml37-40

Security Configuration

Secrets Management

Sensitive configuration can be stored in Kubernetes Secrets:

Secrets are mounted at /etc/secrets/<secret-name>:

Sources: infra/charts/feast/charts/feature-server/values.yaml26-29 infra/charts/feast/charts/feature-server/values.yaml133-134

Pod Security

Sources: infra/charts/feast/charts/feature-server/values.yaml127-140

Version Information

The current version is 0.58.0 across all components:

• Maven artifact version: 0.58.0
• Docker image tag: 0.58.0
• Helm chart version: 0.58.0
• Helm app version: v0.58.0

Version information is returned by the GetFeastServingInfo RPC:

Sources: java/pom.xml38 infra/charts/feast/Chart.yaml4 infra/charts/feast/charts/feature-server/Chart.yaml4-5 protos/feast/serving/ServingService.proto37-40