---
title: "Tutorial: Serve real-time Feast features with Aerospike"
description: "Materialize Feast feature views into Aerospike and read multi-feature-view lookups from a shared Aerospike record."
---

# Tutorial: Serve real-time Feast features with Aerospike

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

::: note
Developers and ML engineers serving features online with Feast.
:::
::: undefined
This tutorial should take between 30 and 45 minutes.
:::

## Objectives

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

-   Register two Feast feature views on one entity and materialize both into Aerospike with `feast apply` and `feast materialize-incremental`.
-   Inspect the shared Aerospike record layout and identify its storage benefit, shared TTL, and per-feature-view read behavior.
-   Observe a targeted Map CDT update when you materialize one feature view on a shared record.

## Introduction

Imagine a logistics app that scores delivery drivers before assigning them rides. The scoring model needs two sets of values: the driver’s recent delivery stats from one data source, and a live demand adjustment from another. Different teams own those sources and update them on different schedules. At assignment time, the app needs both values together and fast.

[Feast](https://feast.dev/) is an open-source feature store for machine learning. The [Aerospike online store for Feast](https://github.com/feast-dev/feast/blob/master/docs/reference/online-stores/aerospike.md) stores an entity’s feature views together on one Aerospike record.

This tutorial explains the Aerospike record layout Feast uses for collocated feature views and how Map CDT partial upserts protect data when teams update views independently. For the broader feature-store workflow with Spark and model serving, start with [Part 1: Feature Engineering](https://aerospike.com/docs/develop/feature-store) or the [end-to-end Feature Store tutorial](https://aerospike.com/docs/develop/tutorials/applications/feature-store).

**Why feature views share a record:** When every feature view for one entity shares a single online record, that pattern is _collocated feature serving_. The Aerospike online store uses it to reduce record-key and primary index (PI) overhead as feature views are added.

One record per entity means fewer record keys and primary index entries as you add feature views. The tradeoff is that feature views on different schedules share one write target and one record-level time to live (TTL). A write that replaced the entire `features` map could replace another feature view’s values. Map CDT partial upserts update only the targeted feature view’s map entries inside the shared record.

For reads, TTL, and `FeatureView.ttl`, see [Benefits and boundaries](https://aerospike.com/docs/develop/feast-aerospike-online-store/step/2/part/0/entity-record-layout#benefits-and-boundaries).

In this tutorial, you register two feature views on the same `driver` entity, materialize both into Aerospike, inspect the shared record layout, and observe a targeted update to one feature view.

## Key terms

| Term | Meaning |
| :-- | :-- |
| Entity | The object a feature describes, identified by a join key (for example, `driver_id`). |
| Feature view | A named group of related features for one entity, backed by a data source. |
| Offline store | The historical store (data warehouse, object storage, or local files) where raw feature values are held for training and backfill. |
| Online store | The low-latency store Feast reads from at inference time. It holds only the latest value per entity. Aerospike is one implementation. |
| `feast apply` | Command that reads your project’s Python definitions and registers the entities, feature views, and feature services in the Feast registry. |
| Materialization | The step that copies the latest feature values from the offline store into the online store. |
| `get_online_features` | The Feast SDK call that reads feature values for one or more entities from the online store. |

## When to use this pattern

Use this tutorial when you:

-   Serve features from more than one feature view for the same entity at inference time.
-   Need to understand how Aerospike stores collocated feature views before working with namespace overrides or push sources.
-   Want to see how Map CDT partial upserts work when feature views share a record and update on different schedules.

For related patterns on the same online store:

-   [Tutorial: Route hot and cold Feast features to memory and flash](https://aerospike.com/docs/develop/feast-aerospike-tiering) when memory cost dominates and you need to separate hot and cold storage tiers.
-   [Tutorial: Stream fraud velocity features with Feast](https://aerospike.com/docs/develop/feast-aerospike-fraud-velocity) when scoring depends on fresh writes from a streaming pipeline instead of batch materialization.

## What you do

-   Register a `driver` entity with two feature views, `driver_stats` and `pricing`, and materialize both into Aerospike.
-   Read features from both feature views in one `get_online_features` call, then inspect the shared Aerospike record directly.
-   Materialize a new batch of `driver_stats` data only and observe that only the `driver_stats` map entries change on each record.

On the next page, you install Feast, the Aerospike Python client, and the Aerospike online store extra.

::: undefined
-   I understand why the Aerospike online store colocates feature views on one record per entity and what tradeoffs that creates.
:::

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