Online Store

The defining characteristic of an online store is its ability to serve feature vectors with single-digit millisecond latency. Unlike the offline store, which is optimized for high-throughput batch scans, the online store uses key-value access patterns to retrieve the latest feature values for a specific entity ID instantly. This is critical for real-time use cases like fraud detection and dynamic pricing, where a decision must be made within the span of a single HTTP request. Architectures typically leverage in-memory databases like Redis or Aerospike to bypass disk I/O bottlenecks.

The online store must serve the latest materialized values for every feature in a vector. This requires a strict synchronization contract with the offline store and streaming pipelines. When a model calls the Serving API, the online store assembles features from multiple Feature Groups into a single, ordered Feature Vector. The system guarantees that the served vector is a consistent snapshot, preventing scenarios where a model receives a stale user_click_count alongside a fresh session_duration, which would corrupt the prediction.

Since the online store sits directly in the critical path of user-facing predictions, it must be designed for five-nines availability (99.999%). This is achieved through active-active replication across multiple availability zones. If a primary node fails, the Serving API must seamlessly failover to a replica without dropping requests. Common strategies include using consistent hashing for sharding and maintaining a Feature Cache as a hot in-memory buffer to absorb traffic spikes during infrastructure outages.

The online store is optimized for point lookups by Entity keys, such as user_id or product_sku. It is not designed for complex analytical queries. The storage engine uses highly compact, low-cardinality indexes to map an entity ID directly to a memory address or disk block. This is fundamentally different from a vector database, which performs approximate nearest neighbor search. The online store performs exact match retrieval, ensuring that the features for user_123 are fetched with zero false positives.

To manage memory costs, online stores implement Time-to-Live (TTL) policies on feature values. Stale features that exceed their Feature Freshness SLA are automatically evicted. For example, a user_session_features group might have a TTL of 30 minutes, while user_demographics might persist indefinitely. This mechanism prevents the online store from becoming a bloated replica of the offline store and ensures that models explicitly fail or fall back to defaults if real-time data has not been refreshed.

The online store is populated not by direct writes from application code, but through a materialization process triggered by Change Data Capture (CDC) streams. When a source database updates a user's profile, a CDC tool like Debezium captures the log event, a stream processor computes the new feature value, and the result is upserted into the online store. This decoupled architecture ensures that the online store is a read-only serving layer, preventing operational load from affecting the source-of-truth databases.

A one-dimensional array of numerical values representing the aggregated features for a specific entity at a specific point in time. This is the payload the online store returns to the model.

• Structure: A concatenation of values from multiple feature groups joined on a single entity key.
• Encoding: All categorical values must be pre-encoded (e.g., one-hot or embeddings) before storage.
• Sparsity: Vectors can be dense or sparse; online stores must handle both efficiently.
• Schema Enforcement: The feature registry defines the exact order and type of each element.

A metric defining the maximum acceptable age of a feature value in the online store. Stale features cause models to act on outdated information, degrading prediction accuracy.

• Real-time Features: Require sub-second freshness, often served via streaming pipelines.
• Near-real-time Features: Tolerate minute-level staleness, updated by incremental materialization.
• Batch Features: May be hours or days old, representing long-term aggregates.
• Monitoring: Track freshness lag as a core data observability metric to trigger alerts.

A data engineering guarantee that feature values used for model training are reconstructed exactly as they existed at a specific historical timestamp. This prevents data leakage from the future.

• Time Travel: The online store's ability to query historical values is essential for generating accurate training datasets.
• Leakage Prevention: Ensures a model trained on yesterday's data did not accidentally see tomorrow's outcome.
• Entity Timestamp: Every feature value is stored with the exact timestamp of its validity.
• Training Dataset Join: The offline store uses this guarantee when joining features to labels.

An in-memory storage layer that holds frequently accessed feature vectors to reduce the latency and load on the primary online store database.

• Redis/Memcached: Common technologies for implementing a feature cache.
• TTL: Time-to-live settings must align with feature freshness requirements.
• Cache Warming: Pre-loading the cache with high-traffic entity keys before peak load.
• Staleness vs. Latency: A trade-off; a longer TTL reduces latency but increases the risk of serving stale data.