A Feature Store is not a single database. It is a dual-storage system designed to serve two fundamentally different workloads: batch training (which needs history and throughput) and real-time inference (which needs the latest value and low latency). Trying to serve both workloads from a single store forces an impossible trade-off.
1. The Offline Store (The Warehouse)
The Offline Store holds the full historical record of every feature value, timestamped, going back months or years.
| Property | Detail |
|---|---|
| Technology | Snowflake, BigQuery, Redshift, Delta Lake on S3 |
| Purpose | Historical feature storage for training dataset generation |
| Access Pattern | Full table scans, time-range queries, point-in-time joins |
| Latency | Seconds to minutes (acceptable for batch jobs) |
| Throughput | Very high — terabytes of data per query |
When a data scientist calls store.get_historical_features(entity_df, feature_refs), the Feature Store executes a point-in-time join against the Offline Store and returns a training-ready DataFrame.
2. The Online Store (The Cache)
The Online Store holds only the most recent value of each feature for each entity. It discards history. Its only job is to answer "what is User 123's current click count?" in under 10 milliseconds.
| Property | Detail |
|---|---|
| Technology | Redis, DynamoDB, Cassandra, Bigtable |
| Purpose | Low-latency feature serving for real-time inference |
| Access Pattern | Key-value lookup by entity ID |
| Latency | 1–10 milliseconds |
| Throughput | Moderate — one feature vector per request |
When a production API calls store.get_online_features(entity_rows, feature_refs), it hits the Online Store and gets back a feature vector in milliseconds.
Materialization: Keeping the Online Store Fresh
The Online Store does not compute features itself. A background process called Materialization reads from the Offline Store (or directly from a streaming source like Kafka) and writes the latest feature values into the Online Store. This job runs on a schedule (e.g., every 15 minutes) or continuously for streaming features.
The materialization gap — the time between when an event occurs and when its computed feature appears in the Online Store — is a key operational metric. A 15-minute materialization interval means your fraud model might be scoring on features that are up to 15 minutes stale.