Design a feature store: system design interview question

How the interviewer opens it

“Design a shared feature platform for machine learning teams. It must support offline model training and low-latency online predictions, with correct historical data and consistent feature values.”

The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.

What to clarify first

Users and feature groups
Data size
Traffic and read:write mix
Latency and training volume
Freshness
Historical correctness
Consistency and availability
Durability and retention
Reproducibility
Scope boundaries

The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.

Scope of a strong answer

Core requirements

Register feature groups with explicit versions and schemas.
Accept feature values and retain their history.
Create training datasets with correct values for each example's cutoff time.
Serve current feature values for online predictions.

Usually out of scope

Build a general feature computation engine.
Train or host models.
Support cross-region writes.
Build a feature discovery interface.

What interviewers ask about

Features for a past prediction: Late values and later corrections can expose information that did not exist at an example's cutoff time.
Agreement between training and predictions: Matching feature names do not ensure matching versions, missing-value rules, or value age limits.
Feature arrival and failures: Two stores must converge despite partial failures, retries, and updates that arrive out of order.
Prediction reads at peak load: Each request needs five groups within 10 ms, while popular entities and failed dependencies can increase tail latency.

Common mistakes

Join training labels to current feature values.
Use event time without acceptance time for historical correctness.
Compute the same feature separately without a shared versioned contract.
Assume one successful write proves that both stores contain the update.
Let late updates replace newer online values.
Treat eventual consistency as permission to return values of unlimited age.

The bar by level

Senior (L5/E5): Defines event time, acceptance time, and revision order. Provides complete dataset snapshots, immutable feature contracts, durable replay, and bounded online read paths.
Staff (L6+/E6+): Defines limits on historical knowledge and exact replay. Designs version migration, recovery, capacity isolation, and explicit behavior when freshness conflicts with availability.

Sources · 1 reference

These records explain where the question appears. A company tag or candidate report does not guarantee a future interview question.

SysRound · 1 record

No company association
Design a feature store
Reported date not specified
Source snapshot: Nov 12, 2026
View source

How the interviewer opens it

“Design a shared feature platform for machine learning teams. It must support offline model training and low-latency online predictions, with correct historical data and consistent feature values.”

The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.

What to clarify first

Users and feature groups

Data size

Traffic and read:write mix

Latency and training volume

Freshness

Historical correctness

Consistency and availability

Durability and retention

Reproducibility

Scope boundaries

The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.

Scope of a strong answer

Core requirements

Register feature groups with explicit versions and schemas.
Accept feature values and retain their history.
Create training datasets with correct values for each example's cutoff time.
Serve current feature values for online predictions.

Usually out of scope

Build a general feature computation engine.
Train or host models.
Support cross-region writes.
Build a feature discovery interface.

What interviewers ask about

Features for a past prediction

Late values and later corrections can expose information that did not exist at an example's cutoff time.

Agreement between training and predictions

Matching feature names do not ensure matching versions, missing-value rules, or value age limits.

Feature arrival and failures

Two stores must converge despite partial failures, retries, and updates that arrive out of order.

Prediction reads at peak load

Each request needs five groups within 10 ms, while popular entities and failed dependencies can increase tail latency.

Common mistakes

Join training labels to current feature values.

Use event time without acceptance time for historical correctness.

Compute the same feature separately without a shared versioned contract.

Assume one successful write proves that both stores contain the update.

Let late updates replace newer online values.

Treat eventual consistency as permission to return values of unlimited age.

The bar by level

Senior (L5/E5)

Defines event time, acceptance time, and revision order. Provides complete dataset snapshots, immutable feature contracts, durable replay, and bounded online read paths.

Staff (L6+/E6+)

Defines limits on historical knowledge and exact replay. Designs version migration, recovery, capacity isolation, and explicit behavior when freshness conflicts with availability.