# Feature stores > A feature store manages the input values that machine learning models use, such as a user's recent watch count or an item's click-through rate. It helps teams reuse feature definitions, build historically correct training data, and fetch fresh values quickly when making predictions. Source: https://sysround.com/concepts/feature-store Updated: 2026-11-05 ## How feature stores works Define each feature with an entity key, calculation, data type, version, and freshness requirement. For example, user_watch_count_1h is keyed by user_id and counts qualifying watch events in a rolling one-hour window. Batch jobs and stream processors calculate feature values from source data. Shared definitions and tests help keep training and serving calculations aligned; a feature store does not automatically eliminate differences between processing paths. An offline store keeps historical values for training and analysis, often in a warehouse or data lake. An online store holds serving-ready values, commonly in a low-latency key-value database; the two stores serve different access patterns. Build training rows with point-in-time joins: for a prediction made at time T, select only feature values available by T. Tracking both event time and availability time prevents late-arriving data or later corrections from leaking future knowledge into training. At prediction time, the service fetches features for user and item keys, combines them with request-time inputs, and calls the model. Batch lookups reduce network overhead, while explicit defaults handle new entities, missing values, and timed-out reads. Publish updates with timestamps or versions so an old replay or backfill cannot overwrite newer online values. Monitor feature age, missing-value rates, distribution changes, and serving latency, and coordinate feature versions with model rollouts. ## Worked example: Fresh watch-history features for a short-video feed Suppose a feed serves 10,000 ranking requests per second and allocates 15 ms of its latency budget to feature retrieval. A stream processor updates each user's one-hour watch count, targeting availability within 30 seconds. Daily jobs compute slower-changing topic preferences. The ranking service batch-fetches the user features and candidate-video features, then combines them with request context. Historical values go to an offline store, where training joins use only values available at each recorded prediction time. If an online lookup times out, the service uses tested defaults or a nonpersonalized ranking. Backfills write historical partitions separately and cannot overwrite newer serving values. ## Trade-offs - **Reuse versus platform complexity.** Shared definitions reduce duplicated pipelines, but introduce registry, ownership, deployment, and compatibility work that a small model application may not need. - **Freshness versus processing cost.** Streaming updates support recent behavior but cost more to operate than periodic batch computation and require policies for late events. - **Fast serving versus duplicated storage.** Separate offline and online stores support their respective workloads but add storage cost, synchronization lag, and reconciliation work. - **Historical accuracy versus data volume.** Point-in-time training requires retained history and availability metadata rather than just the latest value for each entity. - **Prediction availability versus input quality.** Defaults and stale values can keep predictions available during failures, but may reduce model quality and must match tested fallback behavior. - **Shared access versus sensitive data exposure.** Reusable user features require access controls, retention limits, and deletion propagation across historical data, online values, and derived datasets. ## When to use it in a system design interview - Personalized ranking or ad selection needs both historical training data and low-latency access to user and item features. - Multiple models reuse the same behavioral aggregates, and independently implemented calculations are starting to diverge. - Recent events must affect predictions within a stated freshness window without querying raw event history on every request. - The interviewer asks how training avoids future-data leakage or how feature calculations stay consistent between training and serving. ## How to bring it up in the interview - Start with concrete features and requirements: entity keys, update frequency, acceptable age, lookup volume, and the prediction latency budget. - Draw the offline training path separately from the online serving path, then explain which definitions and versions they share. - Walk through one historical training row; expect probes about event time, late arrivals, availability time, and point-in-time joins. - Explain serving failures explicitly: lookup deadlines, batched reads, missing entities, stale values, and a fallback ranking policy. - Defend whether a full platform is necessary; a versioned feature pipeline plus historical tables and a serving database may be enough initially. ## Common mistakes - Treating a feature store as the model server or assuming it trains models; its core responsibility is managing and retrieving model inputs. - Joining historical labels to today's latest feature values, which leaks information that was unavailable at prediction time. - Claiming shared feature names guarantee identical training and serving behavior without checking window boundaries, defaults, and transformation versions. - Using expiration as the only freshness mechanism; a present value can still be too old, and an expired value needs a defined fallback. - Running a historical backfill directly into the online store without preventing older results from replacing newer values. ## Interview questions where it comes up - [Design TikTok](https://sysround.com/questions/design-tiktok): Personalized ranking needs fresh behavioral features at serving time and historically correct versions of those features for training. - [Design an ads serving system](https://sysround.com/questions/design-ad-serving-system): Prediction-based ad ranking needs low-latency user and ad features while campaign eligibility and hard budget enforcement remain separate checks. - [Design a dating app like Tinder](https://sysround.com/questions/design-tinder): Personalized discovery ranking uses profile and interaction features whose training history and serving freshness must be managed separately from blocking and privacy rules. ## FAQ ### What is a feature store in machine learning? A feature store manages named, versioned inputs used by machine learning models. It commonly supports historical retrieval for training and low-latency retrieval for predictions, along with metadata about definitions, ownership, and freshness. ### What is the difference between an online and offline feature store? An online store is optimized for fast lookups of serving-ready values by entity key. An offline store retains historical data for large training queries and point-in-time joins. Many systems use different storage technologies for these two workloads. ### Do I need a feature store for a recommendation system? Not always: a small system can start with versioned batch jobs, historical tables, and precomputed serving values. A feature store becomes more useful when models share features, freshness requirements tighten, or training-serving inconsistencies become difficult to control. It does not replace candidate retrieval, model inference, or ranking logic. ## Related concepts - [Recommendation systems](https://sysround.com/concepts/recommendation-systems) - [Stream processing](https://sysround.com/concepts/stream-processing) - [Materialized views](https://sysround.com/concepts/materialized-views) - [Data lakes and warehouses](https://sysround.com/concepts/data-lake) --- SysRound (https://sysround.com) is an AI practice tool for system design interviews: a voice or typed AI interviewer, a shared whiteboard, then feedback on every skill and a model answer. Its feedback is AI-generated and can be wrong.