Commit 06aa2e5

To validate token signatures the server fetches the provider's JWKS document and caches it, refetching when the cache expires or when a token presents an unknown key id. Two options tune that behavior:

`jwks_cache_lifespan_seconds` also bounds how long a key the provider has **revoked** continues to validate tokens, so lower it if your provider rotates or revokes aggressively; each reduction costs proportionally more JWKS fetches. Key rotations that introduce a new key id are picked up immediately regardless of this setting, because an unknown key id triggers a refetch. `jwks_request_timeout_seconds` bounds how long an unresponsive provider can block request serving. Both must be greater than zero.

{% content-ref url="valkey.md" %}

[valkey.md](valkey.md)

{% endcontent-ref %}

[bigtable.md](bigtable.md)

[Valkey](https://valkey.io/) is an open source (BSD-3-Clause), high-performance key/value datastore hosted by the Linux Foundation, created as a community fork of Redis. It maintains compatibility with the Redis wire protocol, so it can act as a drop-in replacement for Redis. Valkey is also offered as a managed engine by major cloud providers (for example, Amazon ElastiCache for Valkey).

Similar to Redis and [Dragonfly](dragonfly.md), Valkey can be used as an online feature store for Feast: Feast's Redis online store only issues core commands (hash reads/writes, scans, key expiry, pipelines), all of which Valkey implements.

Feast's standard online store operations have been verified against Valkey 8.1: `feast apply`, `feast materialize`, online retrieval via `get_online_features`, `feast teardown`, and key expiry via the `key_ttl_seconds` option. Features that depend on Redis modules (such as vector search) are outside the scope of this page.

Make sure you have Python and `pip` installed.

Install the Feast SDK and CLI

In order to use Valkey as the online store, you'll need to install the redis extra:

Bootstrap a new feature repository:

Update `feature_repo/feature_store.yaml` with the below contents:

Note that the online store `type` remains `redis`: Feast talks to Valkey over the Redis protocol, and all options of the [Redis online store](redis.md) (such as `key_ttl_seconds`) apply unchanged.

There are several options available to get Valkey up and running quickly. We will be using Docker for this tutorial.

The `apply` command scans python files in the current directory for feature view/entity definitions, registers the objects, and deploys infrastructure.

You should see the following output:

The set of functionality supported by online stores is described in detail [here](overview.md#functionality).

Below is a matrix indicating which functionality is supported by the Redis online store, which Feast uses to communicate with Valkey.

| | Redis |

| :-------------------------------------------------------- | :---- |

| write feature values to the online store | yes |

| read feature values from the online store | yes |

| update infrastructure (e.g. tables) in the online store | yes |

| teardown infrastructure (e.g. tables) in the online store | yes |

| generate a plan of infrastructure changes | no |

| support for on-demand transforms | yes |

| readable by Python SDK | yes |

| readable by Java | yes |

| readable by Go | yes |

| support for entityless feature views | yes |

| support for concurrent writing to the same key | yes |

| support for ttl (time to live) at retrieval | yes |

| support for deleting expired data | yes |

| collocated by feature view | no |

| collocated by feature service | no |

| collocated by entity key | yes |

To compare this set of functionality against other online stores, please see the full [functionality matrix](overview.md#functionality-matrix).

# >=2.13 for PyJWKClient's JWK-set cache surviving transient fetch

# failures; the OIDC token parser reuses one client and relies on it.

"pyjwt>=2.13.0",

self._jwks_client: Optional[PyJWKClient] = None # Initialize it lazily.

def _get_jwks_client(self) -> PyJWKClient:

"""Lazily build and cache a parser-lifetime ``PyJWKClient``.

if self._jwks_client is None:

ssl_ctx = ssl.create_default_context()

if not self._auth_config.verify_ssl:

ssl_ctx.check_hostname = False

ssl_ctx.verify_mode = ssl.CERT_NONE

elif self._auth_config.ca_cert_path and os.path.exists(

self._auth_config.ca_cert_path

):

ssl_ctx.load_verify_locations(self._auth_config.ca_cert_path)

self._jwks_client = PyJWKClient(

self.oidc_discovery_service.get_jwks_url(),

headers={"User-agent": "custom-user-agent"},

ssl_context=ssl_ctx,

# Explicit so upgrades cannot silently change the staleness

# window documented above, and so a hung IdP bounds how long

# a fetch can block the serving path.

lifespan=self._auth_config.jwks_cache_lifespan_seconds,

timeout=self._auth_config.jwks_request_timeout_seconds,

)

return self._jwks_client

signing_key = self._get_jwks_client().get_signing_key_from_jwt(access_token)

from pydantic import ConfigDict, Field, model_validator

# How long the fetched JWK set is reused before the server refetches it.

# This also bounds how long a key the IdP has revoked keeps validating

# tokens, so lower it if your provider rotates or revokes aggressively;

# every reduction costs a corresponding increase in JWKS fetches.

jwks_cache_lifespan_seconds: int = Field(default=300, gt=0)

# Network timeout for the JWKS fetch. This fetch happens inline on the

# request path, so an unresponsive IdP blocks serving for at most this

# long.

jwks_request_timeout_seconds: float = Field(default=10, gt=0)