Caching

Features may specify a default caching strategy through the maximum staleness parameter (see Feature Caching for a more in-depth discussion).

However, a request may have freshness requirements that differ from the default caching period specified at the feature level.

You can specify maximum staleness requirements for any set of features, even features you do not wish to return. This facility may be useful if a feature value is used as an intermediate result for an explicitly requested feature.

​

Example

Consider the following feature definition:

@features
class User:
    fico_score: int = feature(max_staleness="30d")
    ...

For most models, it may be acceptable to use a thirty-day old version of the FICO score. However, if you were running a model for issuing a new line of credit, you may require a more updated version of the feature.

By default, our models will receive a FICO score computed in the last 30 days, but we can override this behavior at the time of requesting features for the credit model:

1
2
3
4
5
> chalk query \
      --staleness user.fico_score=10m \
      --in user.id=1 \
      --out user.fico_score

​

Handling null and default values in the cache

You can specify whether to cache null or default feature values using the cache_nulls and cache_defaults parameters in the feature definition. Additionally, customers with a DynamoDB or Redis online store can specify feature(cache_nulls="evict_nulls") to evict any entry that would have been null from the cache, and similarly feature(cache_defaults="evict_defaults") to evict any entry that would have been a default value from the cache if it exists. For more information on how to configure these parameters for your use case, check out our API documentation.

​

Cache busting

Cache busting is a special case of overriding the maximum staleness at the time of making a query. To bypass the cache, simply provide "0s" as the max-staleness.