Data
When Redis Helps — And When It Doesn't
Caching is not a personality trait. On the QC dashboard it turned a 15-second 10k-row fetch into ~5 seconds. It can also hide a bad query for six months.
The case that paid for itself
Quality-control dashboards pull large record sets with filters and pagination. We indexed, stopped fetching columns nobody rendered, and put Redis in front of the frequently accessed slices. Time-to-10k went from ~15s to ~5s. Redis was one lever — not the only one. If you cache a 15-second sequential scan, you still have a 15-second stampede on miss.
What belongs in Redis
Hot keys with a known TTL: session-ish data, last-known vitals, list pages that change slowly, rate-limit counters. Namespaced keys so you never leak tenant A into tenant B. A written invalidation path — not 'we'll figure out cache busting later.' Later is how you ship stale QC data to a plant manager.
What doesn't
The source of truth. Anything you can't afford to lose. Huge values you're too lazy to paginate. And 'cache everything' as a substitute for an index. Redis is a tool for the path you already measured. If you haven't measured, you're decorating.
Takeaway
Put Redis on the read that is hot, correct, and expensive. Fix the query first. Then cache. That order is the whole article.