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

Purpose and Scope

The Java Feature Server is a high-performance, JVM-based implementation of Feast's online feature serving service. It provides low-latency retrieval of feature values for real-time inference workloads. This server is designed for production environments where performance and resource efficiency are critical requirements.

This document covers the Java Feature Server's architecture, deployment model, configuration options, and integration with the broader Feast ecosystem. For information about the Python-based feature server implementation, see Python Feature Server. For the Go implementation, see Go Feature Server.

Sources: infra/charts/feast/README.md1-82 infra/charts/feast/charts/feature-server/README.md1-68

---

Architecture Overview

The Java Feature Server is built on Spring Boot with reactive programming support via Project Reactor. It exposes gRPC endpoints for feature retrieval and is designed to integrate seamlessly with multiple online store backends.

Component Structure

Maven Module Structure

The Java Feature Server is organized into multiple Maven modules:

Module	Purpose
feast-parent	Root POM with shared configuration
datatypes	Protobuf-generated types and data structures
serving	Main feature server implementation
serving-client	Java client library for the server
coverage	Code coverage aggregation

Sources: java/pom.xml18-35 java/pom.xml162-247

Technology Stack

Key Dependencies:

• gRPC Version: 1.63.0 - Used for high-performance RPC communication
• Protobuf Version: 3.25.5 - Protocol buffer serialization
• Reactor Version: 3.4.34 - Reactive programming support for non-blocking I/O
• Netty Version: 4.1.96.Final - High-performance network application framework

Sources: java/pom.xml44-72 java/pom.xml228-232

---

Deployment Model

The Java Feature Server is distributed as a Docker container and deployed via Helm charts on Kubernetes. The primary deployment target is cloud-native environments where it can scale horizontally.

Container Image

The server is published as a Docker image to Quay.io:

quay.io/feastdev/feature-server-java:0.60.0

This image contains:

• Java 11 runtime environment
• Compiled Spring Boot application JAR
• Default configuration (application.yaml)
• Health check endpoints

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

Helm Chart Deployment

Helm Chart Structure:

The feature server is deployed as a subchart within the main Feast Helm chart at infra/charts/feast/charts/feature-server/. The chart creates:

1. Deployment: Manages ReplicaSets and Pods running the feature server
2. Service: Exposes the server on port 6566 (gRPC)
3. ConfigMap: Stores application-override.yaml configuration
4. Secret: (Optional) Stores application-secret.yaml for sensitive config
5. Ingress: (Optional) Exposes the service externally with TLS support

Sources: infra/charts/feast/README.md1-82 infra/charts/feast/requirements.yaml1-15

Service Configuration

The Kubernetes Service exposes the feature server on a ClusterIP by default:

Parameter	Default Value	Description
service.type	ClusterIP	Kubernetes service type
service.grpc.port	6566	Service port for gRPC requests
service.grpc.targetPort	6566	Container port serving gRPC
service.grpc.nodePort	(unset)	NodePort if service type is NodePort

For production deployments, an Ingress resource can be configured to expose the service externally with TLS termination:

Sources: infra/charts/feast/charts/feature-server/values.yaml71-80 infra/charts/feast/charts/feature-server/values.yaml82-122

---

Configuration

The Java Feature Server uses a layered configuration system based on Spring Boot's application.yaml mechanism. Configuration can be provided through multiple sources with clear precedence rules.

Configuration Layers

Configuration Precedence (Lowest to Highest):

1. application.yaml: Default configuration bundled in the JAR
2. application-generated.yaml: Generated by Helm from chart values
3. application-secret.yaml: Sensitive configuration (Kubernetes Secret)
4. application-override.yaml: User-provided overrides (Kubernetes ConfigMap)

Sources: infra/charts/feast/charts/feature-server/values.yaml18-32

Example Configuration

To configure the feature server to use Redis as the online store:

Sources: infra/charts/feast/README.md33-54

Key Configuration Options

Configuration Path	Description
feast.active_store	Name of the active online store configuration
feast.stores	List of online store configurations
feast.entityKeySerializationVersion	Entity key serialization version (2 or 3)
global.registry.path	Path to the Feast registry file
global.registry.cache_ttl_seconds	Registry cache TTL in seconds
global.project	Feast project name
transformationService.host	Host for transformation service
transformationService.port	Port for transformation service

The transformation service configuration allows the feature server to delegate on-demand feature transformations to a separate Python service:

Sources: infra/charts/feast/charts/feature-server/values.yaml13-15 infra/charts/feast/README.md76-82

JVM Options

For production deployments, JVM options can be configured to optimize heap size and garbage collection:

Recommended settings:

• Heap Size: Set -Xms and -Xmx to the same value for predictable performance
• Garbage Collector: Use G1GC (-XX:+UseG1GC) for balanced throughput and latency
• GC Pause Time: Target max pause time with -XX:MaxGCPauseMillis=200

Sources: infra/charts/feast/charts/feature-server/values.yaml34-35

---

Integration with Feast Ecosystem

The Java Feature Server integrates with multiple components of the Feast ecosystem to provide end-to-end feature serving capabilities.

Registry Integration

The feature server loads feature definitions from the registry, which is managed by the Python SDK. The registry contains:

• Feature Views: Schema and metadata for feature definitions
• Entities: Entity definitions with join keys
• Data Sources: Information about offline data sources
• Feature Services: Logical groupings of features

The registry is cached in-memory with a configurable TTL (cache_ttl_seconds) to minimize latency. The server supports multiple registry backend types:

• File-based: Local filesystem or network-mounted storage
• GCS: Google Cloud Storage (gs:// URIs)
• S3: AWS S3 (s3:// URIs)
• SQL: PostgreSQL, MySQL, or other JDBC-compatible databases

Sources: infra/charts/feast/README.md49-52

Online Store Integration

The feature server reads pre-materialized feature values from online stores. Each online store connector implements a common interface for:

1. Key Construction: Building store-specific keys from entity values
2. Batch Reads: Retrieving multiple feature rows in a single operation
3. Deserialization: Converting stored Protobuf Value messages to typed features

The online store type is configured via the feast.stores[].type configuration parameter. Each store type has its own configuration section under feast.stores[].config.

Sources: infra/charts/feast/README.md40-46

Transformation Service Integration

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

The transformation service is configured via:

When deployed via Helm, the transformation service is automatically deployed as a sidecar if transformation-service.enabled: true in the parent Feast chart.

Sources: infra/charts/feast/charts/feature-server/values.yaml13-15 infra/charts/feast/requirements.yaml7-11

---

Operational Characteristics

Health Checks and Probes

The feature server implements Kubernetes health check endpoints for liveness and readiness probes:

Probe Type	Default Config	Purpose
Liveness	initialDelaySeconds: 60 periodSeconds: 10 timeoutSeconds: 5	Determines if the pod should be restarted
Readiness	initialDelaySeconds: 15 periodSeconds: 10 timeoutSeconds: 10	Determines if the pod can receive traffic

Both probes check:

• Server process is running
• gRPC server is accepting connections
• Registry is loaded and accessible

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

Logging Configuration

Logging output format and level are configurable:

• logType: Console: Human-readable format for development
• logType: JSON: Structured JSON logs for production (ELK/Splunk ingestion)

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

Resource Requirements

Resource requirements should be configured based on workload characteristics:

Sizing Guidelines:

• CPU: 1 core can typically serve 1000-5000 QPS depending on feature count
• Memory: 2GB base + (number of feature views × 100MB) for registry cache
• Heap: Set to 50-70% of container memory limit

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

Performance Characteristics

The Java Feature Server is optimized for low-latency feature serving:

• Reactive I/O: Project Reactor enables non-blocking database queries
• Connection Pooling: Reusable connections to online stores reduce overhead
• Registry Caching: In-memory cache eliminates registry roundtrips
• Batch Reads: Multiple entity lookups are batched into single store queries
• Protobuf Serialization: Efficient binary serialization format

Typical latencies (P99):

• Single entity, 10 features from Redis: < 5ms
• Batch of 100 entities, 10 features from Redis: < 20ms
• With on-demand transformations (Python UDF): + 10-50ms overhead

Sources: java/pom.xml71-72 java/pom.xml228-232

---

Build and Release Process

Maven Build

The Java Feature Server is built using Apache Maven with a multi-module structure:

Build artifacts:

• serving/target/feast-serving-{version}.jar - Executable Spring Boot JAR
• serving-client/target/feast-serving-client-{version}.jar - Java client library
• datatypes/target/feast-datatypes-{version}.jar - Protobuf data types

Build requirements:

• Maven: 3.6 or higher
• Java: JDK 11 or higher
• Protoc: 3.12.2 (for regenerating protobufs)

Sources: java/pom.xml354-396

Docker Image Build

Docker images are built as part of the CI/CD pipeline and published to Quay.io:

quay.io/feastdev/feature-server-java:{version}

The image build process:

1. Compile Java code with Maven
2. Package Spring Boot fat JAR
3. Create minimal Docker image with JRE 11
4. Add health check and default configuration

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

Version Management

The version is managed centrally in the parent POM using the ${revision} property:

This version is synchronized with:

• Helm chart versions
• Docker image tags
• Python SDK version
• Go feature server version

The flatten-maven-plugin resolves the ${revision} variable during deployment to Maven Central.

Sources: java/pom.xml37-38 java/pom.xml459-482

---

Comparison with Other Feature Servers

Feature	Java Feature Server	Python Feature Server	Go Feature Server
Runtime	JVM (Java 11+)	CPython 3.10+	Native Go binary
Framework	Spring Boot	FastAPI	Standard library
RPC Protocol	gRPC	gRPC + HTTP	gRPC
Concurrency	Reactive (Project Reactor)	asyncio	Goroutines
Memory Footprint	Medium (JVM overhead)	Low-Medium	Low
Startup Time	Slow (JVM warmup)	Fast	Very fast
Throughput	High	Medium	Very high
Latency P99	5-20ms	10-30ms	3-15ms
Deployment	Kubernetes via Helm	Kubernetes/Docker/Local	Kubernetes/Binary
Primary Use Case	Production serving at scale	Development, prototyping	High-performance production

The Java Feature Server is recommended when:

• You have existing JVM infrastructure and expertise
• You need mature tooling for monitoring and debugging
• You want a stable, battle-tested implementation
• Integration with Java applications is required
• You need enterprise support and SLA guarantees

For maximum performance, consider the Go Feature Server (Go Feature Server). For rapid development and experimentation, use the Python Feature Server (Python Feature Server).

Sources: infra/charts/feast/README.md1-82