---
title: "Namespaces and tiering layout"
description: "How Feast namespace_overrides route feature views and how FeatureServices control requested views."
---

# Namespaces and tiering layout

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

This page explains how `namespace_overrides` routes feature views to different Aerospike namespaces, what that saves, and what it adds to the read path.

On the overview page, you saw how hot and cold feature views route to different Aerospike namespaces. Before you configure the tiered repository, this page explains who owns each part of that setup and how Feast routing choices affect read latency.

## Responsibility split

Tiering spans Aerospike cluster operations and Feast project configuration. The table identifies the owner and mechanism for each concern.

| Concern | Owner | Mechanism |
| :-- | :-- | :-- |
| Memory and flash namespace policies | Aerospike operations | `aerospike.conf`, `storage-engine` per namespace |
| Which feature view uses which namespace | Feast | `online_store.namespace` + `namespace_overrides` |
| Which features a model requests together | Feast | `FeatureService` definitions |

Feast keys `namespace_overrides` by feature view name. Spelling must match the `name=` argument on each `FeatureView` exactly.

## Default namespace and overrides

feature\_store.yaml (production pattern)

```yaml
online_store:

  type: aerospike

  namespace: feast_ssd

  namespace_overrides:

    scoring_velocity: feast_ram
```

-   Feature views without an override land on `feast_ssd` (cold / wide).
-   `scoring_velocity` lands on `feast_ram` (hot).

## Benefits and boundaries

Routing cold views to flash reduces the memory capacity needed for online features. It does not reduce read calls. Feast issues one `online_read` per requested feature view.

A hot-only `FeatureService` controls the tradeoff by requesting fewer views. A full service requests the hot and cold views, adding a read call for each added view. When those views resolve to separate namespaces, the calls also use different storage tiers.

In this tutorial’s local demo, both logical tiers use the Docker `test` namespace so you can run without custom `aerospike.conf`. The YAML structure matches production. Only the namespace names change. The demo verifies that configuration loads and each `FeatureService` returns its expected feature fields. It does not verify namespace override routing, memory or flash placement, or latency differences between tiers.

## Read behavior across tiers

For requests containing at most `batch_max_records` entities (1,000 by default), each `online_read` issues one `batch_operate`. Larger requests issue one `batch_operate` per entity chunk. A service that adds cold feature views adds read calls regardless of whether those views share a namespace. When views are in separate namespaces, those calls target separate records and storage tiers.

Namespace placement controls which storage tier backs each call. A hot-only `FeatureService` that reads only from a memory namespace has lower per-call latency than one reading from a flash namespace. A full service spanning both tiers takes on both the added call count from the extra views and the slower flash reads for the cold views.

Use a hot-only `FeatureService` when the ranking path does not need cold views. Use a full service when the model needs both groups and its latency budget accommodates the additional calls and flash reads.

## TTL across tiers

`ttl_seconds` is an online-store setting that applies the same record-level time to live (TTL) to every Aerospike write, across both tiers. `FeatureView.ttl` controls batch materialization lookback and historical point-in-time retrieval. It does not give the standard Aerospike online read path a separate storage TTL for each view.

This tutorial sets `ttl_seconds` to 30 days so the cold view can remain in Aerospike for its full intended retention period. The hot record has the same storage TTL. Keep hot values fresh through regular writes and monitor their event timestamps.

On the next page, you configure the tiered feature repository.

::: undefined
-   I understand how `namespace_overrides` route feature views to different storage tiers.
-   I understand how feature view selection and namespace placement affect read calls.
:::

[Previous  
Install and connect](https://aerospike.com/docs/develop/feast-aerospike-tiering/step/1/part/1/install-and-connect) [Next  
Configure tiered feature store](https://aerospike.com/docs/develop/feast-aerospike-tiering/step/3/part/0/configure-tiered-store)