Feature Store Architecture Diagrams: Online/Offline Serving with Feast & Tecton (2026)

A feature store is the piece of ML infrastructure that sits between raw data and a model — computing, storing, and serving the numerical inputs ("features") a model needs, consistently, whether that model is being trained on years of historical data or scoring a single request in production milliseconds after it arrives. Feature stores exist to solve one specific, expensive failure mode: training/serving skew, where the features a model was trained on and the features it sees in production quietly diverge, degrading accuracy in ways that are difficult to detect and even harder to debug.

This guide covers the dual-store architecture at the heart of every feature store, the batch and streaming pipelines that populate it, the concept of point-in-time correctness and why it is non-negotiable for training data, and a comparison of the major players — Feast, Tecton, and Databricks Feature Store. It includes ready-to-use prompt templates for generating accurate feature store architecture diagrams.

The problem: training/serving skew

Every ML model that runs in production needs features computed in two very different contexts. During training, features are computed in batch, over historical data, often joining together years of events, aggregations, and slowly-changing dimensions. During serving, the same features need to be computed (or looked up) in real time — typically in single-digit milliseconds — so a model can score a live request such as a page view, a transaction, or a support ticket.

If those two computations are implemented separately — a batch SQL job for training, a hand-written service for serving — they will drift. A subtle difference in a window boundary, a null-handling rule, or a timezone conversion is enough to change a feature's value just slightly between the two paths. The model was trained on one distribution of feature values and is now being served a different one. This is training/serving skew, and it is insidious specifically because it does not throw an error — it just silently erodes model accuracy, often only noticed weeks later when someone asks why a model that scored well offline is underperforming in production.

A feature store solves this by centralizing feature definitions — the transformation logic that turns raw data into a feature — so that both the training path and the serving path execute the identical computation, just against two different backing stores optimized for two very different access patterns.

The dual-store architecture: offline vs online

At the core of every feature store diagram are two physically distinct storage systems, each tuned for a different query pattern. Understanding — and correctly labeling — the boundary between them is the single most important thing to get right in a feature store architecture diagram.

The offline store

The offline store is a data warehouse or lakehouse table — BigQuery, Snowflake, or Parquet files on S3/GCS, frequently organized as an Iceberg or Delta Lake table — that holds the full historical record of feature values over time. It is optimized for large scan-heavy analytical queries, not point lookups. Its primary job is serving training data: given a set of labeled historical events (a user who did or did not churn, a transaction that was or was not fraudulent), the offline store is queried to retrieve the feature values that were true at the time each event occurred, using point-in-time correct joins to avoid leaking future information into the training set.

The online store

The online store is a low-latency key-value store — Redis, DynamoDB, Cassandra, or increasingly Postgres with tuned indexes — that holds only the latest feature values for each entity (a user, a merchant, a device). It is optimized for a single access pattern: given an entity key, return its current feature vector in single-digit milliseconds. There is no historical data here and no complex joins — just a fast key lookup that a model server can call synchronously as part of the inference request path without blowing a latency budget.

The online store never computes anything itself. It is populated by a materialization job that copies (or streams) feature values from the offline store, or directly from a streaming pipeline, into the online store on a schedule or continuously — which is the component that actually keeps the two paths in sync.

Feature pipelines: batch and streaming

Features are computed by pipelines that read raw data and write computed feature values back to the offline store (and, via materialization, eventually to the online store). There are two distinct pipeline types to diagram.

Batch feature pipelines

Batch feature pipelines — typically Spark or dbt jobs — run on a schedule (hourly, daily) against the warehouse or lakehouse, computing features like "total purchases in the last 30 days" or "average session length last week" from historical event tables. These are the workhorse of most feature stores: they are cheap to run, easy to backfill, and well suited to features that do not need to reflect events from the last few minutes.

Streaming feature pipelines

Streaming feature pipelines — built on Flink or Kafka Streams — compute features directly from event streams with low latency, for cases where staleness of even a few minutes is unacceptable. A canonical example is fraud detection: "number of transactions in the last 5 minutes" or "total transaction amount in the last hour" must reflect activity that happened seconds ago, not the last batch run. Streaming pipelines write computed feature values continuously, keeping the online store current with sub-minute freshness.

The two paths every feature store diagram must show

The online serving path

At inference time, a model server receives a request containing an entity key (say, user_id). It queries the online store by that key to retrieve the entity's current feature vector, then joins those retrieved features with any request-time features (values only available at the moment of the request, like the device type or page currently being viewed) before passing the complete feature vector to the model for scoring. This entire round trip typically needs to complete within a tight latency budget — often under 50 milliseconds end to end — so the online store lookup itself must be a small fraction of that budget.

The training path and point-in-time correctness

To build a training dataset, a data scientist provides an entity dataframe — a list of (entity, timestamp, label) rows, for example every user who churned or did not churn and the exact timestamp of that outcome. The feature store then performs a point-in-time-correct join against the offline store: for each row, it retrieves the feature values as they existed at that exact timestamp — not the feature values as they exist today. Getting this wrong is one of the most common and most dangerous mistakes in ML: if a training set is built using current feature values for historical labels, the model is trained on information that would not have been available at prediction time — a form of label leakage that inflates offline accuracy while silently destroying production performance. Diagramming this join explicitly — and annotating it as point-in-time correct — is one of the highest-value things you can do in a feature store architecture diagram, because it is the detail reviewers most often miss.

The feature registry: the shared source of truth

Both paths — training and serving — must compute features using identical logic, and that logic lives in a feature registry: versioned feature view definitions, typically written in a Python SDK or declarative YAML, that specify the transformation, the entity keys, the data sources, and metadata like ownership and freshness SLAs. The registry is what makes a feature store a store and not just two disconnected databases — it is the single definition that both the batch/streaming pipelines and the point-in-time training queries reference, which is precisely what eliminates training/serving skew at the source.

Feast vs Tecton vs Databricks Feature Store

The feature store landscape in 2026 spans open-source frameworks, commercial platforms, and cloud-native offerings built into existing lakehouse platforms. Here is how the major options compare.

A related platform-native alternative worth knowing is Amazon SageMaker Feature Store, which offers the same dual offline/online architecture natively within the SageMaker ecosystem — offline data lands in S3 (queryable via Athena), online data is served from a managed low-latency store, making it a natural default for teams already committed to AWS and SageMaker for training and deployment.

Prompt templates for feature store architecture diagrams

Real-time fraud detection feature store

Recommendation model training pipeline with point-in-time correctness

What to show in your feature store diagram

• Offline vs online store separation — draw them as two distinct systems with different technologies (e.g., Snowflake vs Redis), never as a single generic "database" box; the split is the entire point of the architecture
• Batch vs streaming feature pipelines — show both paths feeding the offline store (and, for streaming, potentially the online store directly) so reviewers can see which features are fresh to the minute and which are refreshed daily
• The materialization job — explicitly diagram the job that copies feature values from the offline store into the online store, including its schedule or continuous-write cadence; this is the component that keeps the two paths in sync
• Point-in-time join annotations on the training path — label the join between the entity/label dataframe and the offline store as point-in-time correct so reviewers understand leakage is being actively prevented, not just assumed
• Latency budgets on the online serving path — annotate the online store lookup and the end-to-end inference request with target latencies (e.g., "<10ms lookup, <50ms total") so the diagram communicates the performance contract, not just the data flow
• The feature registry as shared source of truth — draw the registry as the single component both the training path and the serving path reference, making explicit that skew is prevented by shared definitions, not by coincidence

Frequently asked questions about feature store architecture

Do I need a feature store if I only have one model in production?

Probably not yet. Feature stores earn their complexity when multiple models need to share the same features, when training/serving skew has already caused a production incident, or when feature computation logic has grown complex enough that duplicating it between a training notebook and a serving service is error-prone. A single model with simple, stable features can often get by with a well-tested shared library of transformation functions called from both the training script and the serving code — a feature store becomes worth adopting once that approach starts to strain.

What is the difference between a feature store and a data warehouse?

A data warehouse stores and serves data for analytical queries — it has no concept of an online, low-latency serving path, and no built-in notion of point-in-time-correct joins for ML training sets. A feature store's offline store is frequently built on top of a data warehouse or lakehouse (Snowflake, BigQuery, Iceberg tables on S3), but adds the online store, the materialization layer, the feature registry, and point-in-time join semantics on top — the specific machinery ML systems need that a general-purpose warehouse does not provide out of the box.

Can I use Postgres as an online feature store?

Yes — for moderate throughput and entity cardinality, a well-indexed Postgres table (or Postgres with a caching layer in front) can serve single-digit-millisecond feature lookups and is a common choice for teams that want to avoid operating a separate Redis or DynamoDB cluster. Feast supports Postgres as a pluggable online store backend for exactly this reason. At very high request volumes or very large entity counts, a purpose-built key-value store like DynamoDB or Redis typically offers better latency consistency and horizontal scaling characteristics.

Related guides: LLMOps architecture, model fine-tuning architecture, RAG architecture diagrams, and MLOps pipeline diagrams.