Redis Features: Cache the Online Path, Never the Source of Truth
We trained on warehouse snapshots and served from Redis. TTL eviction and a stampede later, the model looked broken. Online features are a cache, not a fact table.
- redis
- mlops
All stacks · Operational data stores
Caches, feature serving, and when not to treat it as a database.
We trained on warehouse snapshots and served from Redis. TTL eviction and a stampede later, the model looked broken. Online features are a cache, not a fact table.
Redis is the cache and feature-serving plane: sub-millisecond gets, TTLs, and the incident called “we treated Redis as the source of truth.” Data engineers use it for online features, locks, and rate limits — not for last month’s orders.
It can persist, but if losing the instance is a data-loss incident, you designed it wrong. Durable facts live in OLTP or the warehouse. Redis holds derived, replaceable state — unless you explicitly built a Redis-backed product with a backup story.
Same grain, same code path or a checked parity job. Training on a warehouse snapshot and serving a live Redis join that can see the label is leakage. Say that in the design interview.
Warehouse result cache is for SQL repeats. Redis is for application keys. Do not put BI extracts in Redis “for speed” without an owner and a TTL.
One email a week with our latest tutorials. No spam.
Newsletter signup is not live yet. Use the contact form if you want to be notified.