Describe feature store architecture and training-serving skew

WHAT THIS TESTS: Whether you understand the feature store as the governed data layer that connects feature, training, and inference pipelines in an FTI architecture, and whether you can explain how its design specifically prevents training-serving skew through consistent compute and dual storage.

A GOOD ANSWER COVERS: First, the two core storage layers: an offline store that holds historical feature data for batch training and backfilling, and an online store optimized for low-latency point lookups during real-time inference. Second, the query engines that serve point-in-time consistent training data to prevent data leakage, and low-latency feature vectors for online models. Third, the transformation layer that ensures features are computed identically in both offline and online pipelines so the model sees the same distributions at train and serve time. Fourth, the operational benefits: feature reuse across teams, incremental dataset management, governance, and monitoring for drift. Finally, mention that it supports both batch and streaming writes and can even serve approximate nearest neighbor search for embeddings.

COMMON WRONG ANSWERS: Describing the feature store as just a database, data warehouse, or cache without mentioning the compute consistency layer. Ignoring point-in-time correctness and claiming you can simply join the latest feature values to labels. Treating offline and online stores as interchangeable rather than workload-specific. Failing to mention that the store precomputes features to provide history and context for stateless online models. Overlooking the FTI pipeline decomposition that lets data engineers, data scientists, and ML engineers own separate pipelines independently.

LIKELY FOLLOW-UPS: How would you handle streaming feature updates versus batch backfills? What is the difference between a feature store and a vector database? How do you monitor for training-serving skew after deployment? When would you compute features on-demand versus precomputing them? How does the store handle embedding storage and approximate nearest neighbor search?

ONE CONCRETE EXAMPLE: Imagine a fraud detection model that needs a users thirty-day transaction average. In training, the query engine retrieves the point-in-time correct average for each historical label so future transactions do not leak into the training set. The same feature pipeline computes and writes that rolling average to both the offline store and the online store. At inference time, the online store serves the precomputed average with low latency, and because the identical transformation logic was applied in both paths, the model receives a consistent feature vector and training-serving skew is eliminated.