Feature Stores
Advanced 16 min read Feature Stores

Feature Store Architecture

The components and trade-offs behind the features

Feature stores have real components — registry, offline compute, online store, sync, SDK layer — and real trade-offs: self-host Feast vs managed, batch-only vs streaming, fat vs thin SDK.

feature store architecturesource of truthfeastsnowflake feature storeregistry
Prerequisites: Feature Stores Production ML Architecture
Before we start

What you will learn

  • List the architectural components of a feature store
  • Compare self-hosted and managed options
  • Weigh freshness architecture: batch, streaming, or both
Introduction

What is this?

A feature store architecture composes: a registry of feature definitions, offline compute and storage, an online low-latency store, a sync path between them, and an SDK for consumers. The key trade-offs — open-source self-hosted (Feast) vs managed, batch vs streaming freshness, SDK thickness — depend on team size, latency needs and compute already in use.

Motivation

Why do you need it?

  • Understanding components lets you integrate with your existing stack instead of bolting on a monolith.
  • Freshness requirements dictate whether batch-only suffices or streaming is worth its cost.
  • The registry is the contract: get that wrong and the whole system lies.
  • Managed vs self-hosted is a total-cost and control decision, not a fashion choice.
Think about it

Mental model

Imagine

City waterworks: reservoir, pump station, pipes, household taps

Think of

Feature store components

The reservoir (offline store) holds the big history; the pump station (sync) keeps pressure up; the pipes (online store) serve taps fast; the taps (SDK) just turn on water. All parts matter, and you can't skip the reservoir because the taps need it later.

Mechanics

How it works

  • The registry stores feature definitions, owners, freshness SLAs and versioning metadata.
  • Offline compute runs transformations against a warehouse/lake into versioned tables.
  • The online store (Redis, DynamoDB, embedded) serves low-latency reads.
  • A sync/streaming layer refreshes online values from offline materialization.
  • The SDK exposes training-matrix fetches and real-time retrievals uniformly.
  • Observability components measure staleness, consistency and usage.

Reference feature store components and flows.

Registry
Offline compute
Online store
Sync path
SDK
Observability
Real world

In production

  • A mid-size platform self-hosts Feast on S3 + DynamoDB, mapping warehouse-adjacent workflows to batch freshness.
  • A high-frequency fraud platform runs streaming feature computation (Flink) feeding the online store.
  • A data-heavy enterprise uses a managed store built on its lakehouse to avoid another self-hosted service.
Guidelines

Best practices

  • Start with batch freshness unless a decision truly needs sub-minute values.
  • Keep the registry authoritative and versioned like code.
  • Choose storage your data team already owns for the offline path.
  • Instrument staleness and consistency from day one.
Watch out

Common mistakes

  • Buying a store and keeping all the old duplicated feature computation anyway.
  • Streaming-everything because 'real-time is better' — costing complexity with no decision payoff.
  • Fat SDKs that leak store details into every model repo.
  • No offline store, so backfills and point-in-time correctness are impossible.
When things break

Debugging tips

  • Store outage? The SDK should fail according to declared semantics, not vanish.
  • Sync job backlog? Watch the lag queue size, not just the last successful run.
  • Registry drift — reconcile definitions against actual materialized tables.
Interviews

Interview checkpoint

Test yourself

Quick quiz

0/2
1

Which component holds the feature definitions and metadata?

2

Streaming freshness is required for every feature in a modern store.

Go deeper

Official documentation

Feast architecture overview
docs