---
title: "Tutorial: Route hot and cold Feast features to memory and flash"
description: "Validate a local namespace_overrides configuration and prepare to route Feast feature views to memory and flash namespaces."
---

# Tutorial: Route hot and cold Feast features to memory and flash

> For the complete documentation index see: [llms.txt](https://aerospike.com/docs/llms.txt)
> 
> All documentation pages available in markdown.

::: note
MLOps and platform engineers managing growing Feast online store capacity and cost.
:::
::: undefined
This tutorial should take between 25 and 40 minutes.
:::

## Objectives

By the end of this tutorial, you will be able to:

-   Validate the `namespace_overrides` structure locally and identify the namespace changes required for production tiering.
-   Identify the storage benefit, read tradeoff, and local-demo boundary of namespace routing.
-   Define hot-only and full `FeatureService` objects, then compare the feature views each service requests.

## Introduction

Imagine an online store whose recommendation model ranks products for a user on every page view. The ranking reads a few fast-changing signals, such as how many items the user viewed and how much they spent in the last hour. That same user also has slower-moving profile values, such as lifetime value and a category affinity score, that only a nightly email campaign job and an internal analytics dashboard read. Everything lives in the same online store, so the profile values occupy memory even though nothing on the ranking path reads them.

Aerospike storage tiers differ in read speed and in cost per byte: memory serves reads faster, and flash holds far more data for the same money. If your online feature set is large but only a small part of it needs the fastest reads, routing the rarely read feature views to flash reduces memory use without adding separate infrastructure.

[Feast](https://feast.dev/) routes feature views to Aerospike namespaces through `namespace_overrides` in `feature_store.yaml`. Aerospike hybrid memory architecture and device paths are set in `aerospike.conf`. Feast only needs the namespace name.

**Why route feature views by storage need:** _Tiering_ means routing different feature views to different storage namespaces based on how often they are read and how much latency they can tolerate. Hot feature views can use an in-memory namespace when they require lower read latency than flash storage. Cold feature views use flash storage instead of memory.

| Tier | Example | Aerospike namespace |
| :-- | :-- | :-- |
| Hot | `scoring_velocity`: item views and spend in the last hour, read on every ranking request | Memory namespace (for example `feast_ram`) |
| Cold | `user_profile_wide`: lifetime value and affinity score, read by the nightly campaign job and the analytics dashboard | Flash namespace (for example `feast_ssd`) |

The tradeoff is that every requested feature view still adds a read call, and flash-backed calls can take longer than memory-backed ones. A hot-only `FeatureService` keeps cold views off the latency-sensitive ranking path.

The local demo uses one Docker namespace. See [Benefits and boundaries](https://aerospike.com/docs/develop/feast-aerospike-tiering/step/2/part/0/namespaces-and-tiering#benefits-and-boundaries) for what it verifies and what production tiering requires.

The same shared-record behavior from [Tutorial: Serve real-time Feast features with Aerospike](https://aerospike.com/docs/develop/feast-aerospike-online-store) applies to feature views that resolve to the same namespace and set.

## Key terms

| Term | Meaning |
| :-- | :-- |
| Tiering | Routing different feature views to different Aerospike namespaces based on how often they are read and how much latency they can tolerate. |
| `namespace_overrides` | Feast configuration field in `feature_store.yaml` that maps feature view names to Aerospike namespaces. |
| `feast apply` | Command that reads your project’s Python definitions and registers the entities, feature views, and feature services in the Feast registry. |
| Hot `FeatureService` | Groups only latency-critical feature views on one tier. |
| Full `FeatureService` | Groups hot and cold views when a background or lower-priority consumer, such as a campaign job or a dashboard, needs both tiers. |
| Cross-namespace read | A request whose feature views resolve to more than one Aerospike namespace. Feast still issues one read per feature view. |

## When to use this pattern

Use this pattern when you:

-   See memory-store bills growing faster than traffic.
-   Have many features per entity but only a small subset on the real-time ranking path.
-   Need a governed YAML route from one Feast project to memory and flash namespaces.

Skip tiering when your entire online working set is small and every feature needs the same low latency. A single namespace requires less operational work.

## What you do

-   Validate a local `feature_store.yaml` structure with a default namespace and `namespace_overrides`.
-   Define `scoring_velocity` (hot) and `user_profile_wide` (cold) feature views plus hot-only and full `FeatureService` objects.
-   Materialize both views and compare the feature views requested by each service.

To implement physical tiering, configure separate memory and flash namespaces in `aerospike.conf`, then replace the two `test` values before `feast apply`.

On the next page, you install Feast and Aerospike locally.

::: undefined
-   I understand the storage benefit, read tradeoff, and configuration boundary of routing feature views across Aerospike namespaces.
:::

[Next  
Prerequisites](https://aerospike.com/docs/develop/feast-aerospike-tiering/step/1/part/0/prerequisites)