The Feature Store That Ate the BudgetWarehouse · medium · ~12 minYour feature store's infrastructure line has doubled two quarters running. The fleet: 84 Redis nodes (memory-priced), serving 6M feature reads/sec to the prediction services. Feature count grew 8× this year and keeps climbing.The platform review turns up three exhibits. One: every feature is stored as its own key (avg_order_value_90d__user_12345 → value); a typical prediction fetches 80 features for each of 40 entities — 3,200 GET commands per prediction call. Two: traffic analysis shows the same hot entities (busy merchants, active users) fetched thousands of times per minute at full price. Three: 60% of stored bytes belong to high-cardinality item-pair features read less than once a month, sitting in RAM.Leadership wants a plan that bends the curve without a rewrite of the prediction services.Evidence

The exhibits, quantified

Access pattern profile

Constraints

Checkpoints

Exhibit one: 3,200 commands per prediction, entity features scattered across all shards. What's the layout fix and its primary effect?

Exhibit two: 76% of reads hit the top-1% of entities. If an in-process client cache achieves a hit rate equal to that repetition share, roughly what fraction of current Redis read volume remains? (Answer as a percentage.)

Exhibit three: 60% of stored bytes are high-cardinality, read <1×/month, in RAM. The right move?

Write the plan: sequence the three fixes with expected magnitudes, the encoding detail that exhibit-one's value-type profile suggests, and the validation step each fix needs before full rollout.