DataLane

All stacks · Operational data stores

Redis

Caches, feature serving, and when not to treat it as a database.

Redis cover

About Redis

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.

What you'll learn here

  • What belongs in Redis vs the warehouse vs OLTP
  • TTL, eviction, and cache stampede
  • Redis as an online feature store sidecar
  • Persistence (AOF/RDB) and why “it is just a cache” is a lie the first time it is not

Frequently asked questions

Is Redis a database?

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.

How do online features stay consistent with batch?

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.

Redis or the warehouse result cache?

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.

New Redis posts, straight to your inbox

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.

↑↓ navigate openesc close