feature store

Half the value of this question is the second clause. Feature stores solve three specific problems, and FDEs earn trust by naming the team sizes and model counts below which they're expensive overkill.

The most expensive leakage bug in feature-store ML: training joins that grab feature values from after the label event. The timeline that exposes it, the one query that proves it, and the fix that survives audit.

Candidates describe a feature store as 'a database for features' and fail, it's a consistency machine with two faces. The online/offline split, the latency numbers each side must hit, and when you shouldn't build one.

The bug that makes offline metrics a lie: training on information that didn't exist at prediction time. A concrete fraud example with timestamps, the as-of join that fixes it, and the label-maturity trap automated retraining adds on top.

The bug class with no stack trace: the model is fine, the pipelines are green, and production quietly underperforms offline by five points. Why skew survives even feature-store adoption, and the log-and-wait pattern Google-style answers center on.

A bank-round system design where the budget math does the screening: ~10ms for features inside a 100ms decision. Streaming aggregates, the hot-key problem during an active attack, and the parity discipline that makes training data honest.