You might not need Redis
Engineers debate when Redis is genuinely warranted versus when it’s an unnecessary layer of complexity added out of habit or premature optimization. Many argue that relational databases, in‑process caches, or simpler key–value stores are sufficient for most workloads under modest QPS, reserving Redis for cases that truly need fast shared data structures, cross‑process coordination, or probabilistic structures. Others emphasize that while Redis is technically elegant and powerful, its misuse as a primary data store, overuse for trivial caching, and operational pitfalls (persistence, clustering, outages) often outweigh its benefits in typical applications.
Redis’ Reputation and Perceived Quality
- Strong praise for core Redis as “magnificently written” and extremely solid; some single servers run huge QPS for long uptimes.
- Counterpoint: in some companies Redis is outright banned after outages, especially around Sentinel/cluster and replication.
- Redis Search is called buggy; core server generally respected, but client libraries and distributed usage have caused CVEs and bad experiences.
- Main concern is less the API and more the operational hazards and misuse.
When Redis Is the Right Tool
- Well-suited for high-velocity, weakly-durable data: counters, feeds, chat, rate limiting, leaderboards, matchmaking, sessions, TTL caches.
- Valued as a “data structure server”: lists, sets, sorted sets, bitmaps, probabilistic structures (Bloom, HyperLogLog, Top-K, etc.), streams and queues.
- Very handy when many services in different languages must share state or data structures.
Overuse, Premature Optimization, and Simpler Alternatives
- Many comments say most apps (especially far below tens of thousands of QPS) can just use MySQL/Postgres with good indexing, or even SQLite.
- Local in-process caches (hashmaps, Caffeine/Guava, etc.) are often faster and simpler than a networked Redis, if data isn’t shared across nodes.
- Memcached is preferred by some for simple KV caching because it’s constrained in scope and operationally simpler.
- Several note that people copy FAANG-style stacks (Redis, Kafka, Elastic, NoSQL) at tiny scales, adding complexity for no benefit.
Redis as Persistent / Transactional Store: Warnings
- Multiple reports of pain using Redis as a durable datastore: Sentinel/cluster flakiness, replication breakage, outages.
- Skepticism about using it for transactional or “active-active” scenarios; documentation on conflict resolution and distributed locks seen as weak.
- Several teams now use Redis strictly as ephemeral cache or buffer; design rule: the system must survive a full cache flush.
Anecdotes and Broader Lessons
- High-profile pricing/geo systems were massively over-built on Redis, then successfully replaced by algorithms on a single machine plus Elasticsearch or DB features.
- Horror stories of people building ad-hoc relational schemas inside Redis instead of using a real database.
- Theme that adding any new datastore brings nontrivial cost in management, scaling, backup, and incident risk.
- Broader critique: industry often follows infrastructure fads (Redis, NoSQL) instead of carefully reasoning about the actual performance problem.