feat: Adding Feature Server to components docs

Signed-off-by: Francisco Javier Arceo <[email protected]>

docs/SUMMARY.md

@@ -32,6 +32,7 @@
   * [Registry](getting-started/components/registry.md)
   * [Offline store](getting-started/components/offline-store.md)
   * [Online store](getting-started/components/online-store.md)
+  * [Feature server](getting-started/components/feature-server.md)
   * [Batch Materialization Engine](getting-started/components/batch-materialization-engine.md)
   * [Provider](getting-started/components/provider.md)
   * [Authorization Manager](getting-started/components/authz_manager.md)

docs/getting-started/components/README.md

@@ -12,6 +12,10 @@
 [online-store.md](online-store.md)
 {% endcontent-ref %}
 
+{% content-ref url="feature-server.md" %}
+[feature-server.md](feature-server.md)
+{% endcontent-ref %}
+
 {% content-ref url="batch-materialization-engine.md" %}
 [batch-materialization-engine.md](batch-materialization-engine.md)
 {% endcontent-ref %}

docs/getting-started/components/feature-server.md

@@ -0,0 +1,40 @@
+# Feature Server
+
+The Feature Server is a core architectural component in Feast, designed to provide low-latency feature retrieval and updates for machine learning applications.
+
+It is a REST API server built using [FastAPI](https://fastapi.tiangolo.com/) and exposes a limited set of endpoints to serve features, push data, and support materialization operations. The server is scalable, flexible, and designed to work seamlessly with various deployment environments, including local setups and cloud-based systems.
+
+## Motivation
+
+In machine learning workflows, real-time access to feature values is critical for enabling low-latency predictions. The Feature Server simplifies this requirement by:
+
+1. **Serving Features:** Allowing clients to retrieve feature values for specific entities in real-time, reducing the complexity of direct interactions with the online store.
+2. **Data Integration:** Providing endpoints to push feature data directly into the online or offline store, ensuring data freshness and consistency.
+3. **Scalability:** Supporting horizontal scaling to handle high request volumes efficiently.
+4. **Standardized API:** Exposing HTTP/JSON endpoints that integrate seamlessly with various programming languages and ML pipelines.
+5. **Secure Communication:** Supporting TLS (SSL) for secure data transmission in production environments.
+
+## Architecture
+
+The Feature Server operates as a stateless service backed by two key components:
+
+- **[Online Store](./online-store.md):** The primary data store used for low-latency feature retrieval.
+- **[Registry](./registry.md):** The metadata store that defines feature sets, feature views, and their relationships to entities.
+
+## Key Features
+
+1. **RESTful API:** Provides standardized endpoints for feature retrieval and data pushing.
+2. **CLI Integration:** Easily managed through the Feast CLI with commands like `feast serve`.
+3. **Flexible Deployment:** Can be deployed locally, via Docker, or on Kubernetes using Helm charts.
+4. **Scalability:** Designed for distributed deployments to handle large-scale workloads.
+5. **TLS Support:** Ensures secure communication in production setups.
+
+## Endpoints Overview
+
+| Endpoint                   | Description                                                             |
+| -------------------------- | ----------------------------------------------------------------------- |
+| `/get-online-features`     | Retrieves feature values for specified entities and feature references. |
+| `/push`                    | Pushes feature data to the online and/or offline store.                 |
+| `/materialize`             | Materializes features within a specific time range to the online store. |
+| `/materialize-incremental` | Incrementally materializes features up to the current timestamp.        |
+

docs/getting-started/components/overview.md

@@ -13,6 +13,7 @@
 * **Deploy Model:** The trained model binary (and list of features) are deployed into a model serving system. This step is not executed by Feast.
 * **Prediction:** A backend system makes a request for a prediction from the model serving service.
 * **Get Online Features:** The model serving service makes a request to the Feast Online Serving service for online features using a Feast SDK.
+* **Feature Retrieval:** The online serving service retrieves the latest feature values from the online store and returns them to the model serving service.
 
 ## Components
 
@@ -24,6 +25,7 @@ A complete Feast deployment contains the following components:
   * Materialize (load) feature values into the online store.
   * Build and retrieve training datasets from the offline store.
   * Retrieve online features.
+* **Feature Server:** The Feature Server is a REST API server that serves feature values for a given entity key and feature reference. The Feature Server is designed to be horizontally scalable and can be deployed in a distributed manner.
 * **Stream Processor:** The Stream Processor can be used to ingest feature data from streams and write it into the online or offline stores. Currently, there's an experimental Spark processor that's able to consume data from Kafka.
 * **Batch Materialization Engine:** The [Batch Materialization Engine](batch-materialization-engine.md) component launches a process which loads data into the online store from the offline store. By default, Feast uses a local in-process engine implementation to materialize data. However, additional infrastructure can be used for a more scalable materialization process.
 * **Online Store:** The online store is a database that stores only the latest feature values for each entity. The online store is either populated through materialization jobs or through [stream ingestion](../../reference/data-sources/push.md).