Do You Actually Need One?
In one line: a feature store solves real problems at a scale most teams have not reached, and proposing one for a single model is the same mistake as proposing a vector database for ten thousand documents.
The five signals
The useful heuristic: count how many of these are true. Fewer than about three and simpler alternatives are better.
| Signal | What it looks like | Why a store helps |
|---|---|---|
| Several models share features | Two teams both compute 'user lifetime value', differently | One definition, one owner, one number |
| You have had a skew incident | Offline excellent, production poor, cause took weeks | The class of bug becomes structurally impossible |
| Feature work bottlenecks iteration | Adding a feature means a pipeline and a serving change | Define once, both paths follow |
| You need real-time freshness | Session-scoped signals matter and batch cannot deliver them | Streaming materialisation into the online store |
| Teams duplicate each other | Three implementations of 'days since signup' | Discovery — the largest benefit, and organisational |
The first and last rows are the ones that actually justify the investment in most organisations, and both are about people, not technology. A feature store is at heart a coordination mechanism, and it pays off in proportion to how many teams need coordinating.
What to do instead
Three alternatives, in increasing order of what they cost and cover.
A shared transformation library. Both paths import the same function. Cheap, immediate, and it closes the largest single gap. It does not solve point-in-time correctness, and it does not stop the inputs differing — but it kills the window-boundary and null-handling class of bug outright.
A materialised view plus a key-value cache. Compute features in the warehouse on a schedule, publish the latest values to Redis, read from Redis at serving. That is a feature store's core mechanism, hand-built, without the registry, versioning or point-in-time machinery. For one or two models it is entirely reasonable.
Log the features you served. The pattern from the ranking chapter: record the exact feature vector alongside each decision and join labels to it later. This sidesteps point-in-time correctness completely — the training row is by construction what the model saw — and it costs storage plus a waiting period rather than a platform.
Log-and-serve deserves emphasis because it is under-used relative to how well it works. It gives correct training data without any historical reconstruction, and its weakness is specific: you can only train on features you were already serving. Adding a new feature means serving it — even unused — for as long as your training window needs, before you can train on it. That delay is the real cost, and for a fast-moving team it can be decisive either way.
What a feature store costs
Being concrete, because "adds complexity" is not an argument anyone can act on.
A service to operate. Registry, pipelines, two stores, materialisation jobs. In the serving path, so its availability becomes your model's availability.
A definition language to learn. Features expressed in the store's abstractions rather than plain SQL. Real friction for people who were productive before.
Pipeline maintenance. Definitions evolve, sources change schema, backfills are needed. This does not stop.
A new failure mode. Materialisation lagging or failing means the online store serves stale values, and stale-but-present is worse than absent because nothing errors.
The honest position for an interview
Both extremes are wrong answers, and saying so is the strong move.
Reaching for a feature store on any ML system design is the same over-engineering reflex as reaching for Kafka on a system with a hundred events a day. And dismissing it entirely leaves you with no answer for how two code paths stay consistent at scale.
"I'd start with a shared transformation library and log the served feature vectors — that gets correct training data and kills most skew for very little. I'd move to a feature store when several teams start needing the same features, or when we've had a skew incident that took weeks to diagnose. Those two are what actually justify it, and both are coordination problems rather than technical ones."
Key takeaway
Count the signals: shared features across models, a skew incident, feature work bottlenecking iteration, real-time freshness needs, duplicated work across teams. Fewer than about three and a shared transformation library plus logging the served feature vectors gets most of the benefit for almost none of the cost — and logging sidesteps point-in-time correctness entirely, at the price of only being able to train on features you already serve. A feature store is fundamentally a coordination mechanism, so it pays off in proportion to how many teams need coordinating, and it adds a failure mode of its own: stale-but-present values that never error.
Next: the two stores, and why they are optimised for opposite things.