Redis as a Cache vs a Primary Data Store: What Changes?
Learn what changes when Redis is used as a cache versus a primary data store, including persistence and failover needs.
Expected Interview Answer
Using Redis as a cache means treating it as disposable, rebuildable-from-source data that the application never needs to survive as its only copy, whereas using Redis as a primary data store means it holds data that exists nowhere else, so durability, persistence, and backup strategy become mandatory rather than optional.
As a cache, Redis entries can be evicted, expired, or lost on a restart without permanent harm, because a cache-aside or similar pattern regenerates them from the database of record on the next miss — this lets teams run Redis with weaker persistence settings (or none) for maximum speed. As a primary store, that safety net disappears: the application must enable AOF or RDB persistence, configure replication and possibly Redis Sentinel or Cluster for failover, and treat data loss as a real incident rather than a minor cache miss, since there is no other database holding the same rows. The decision also changes query design, since Redis's data structures (strings, hashes, sorted sets, streams) support fast key-based access and specific patterns well but lack general-purpose ad hoc querying, joins, and strong transactional guarantees across many keys that a relational database provides.
- As cache: can run with minimal persistence for maximum throughput
- As cache: data loss is recoverable by reloading from the database
- As primary store: predictable low-latency access to structured data
- As primary store: purpose-built structures (sorted sets, streams) for specific access patterns
AI Mentor Explanation
A sticky note of today's playing eleven kept at the scorer's desk is fine to lose — if it blows away, the scorer just re-copies it from the official team sheet on file, no harm done, exactly how Redis-as-cache treats data as disposable and rebuildable. But if a club started keeping its only copy of every player's career statistics on loose sticky notes with nothing filed anywhere else, losing that desk would erase history permanently — that is the risk of using Redis as a primary store without real persistence and backups.
Step-by-Step Explanation
Step 1
Decide the role
Determine whether Redis will hold rebuildable derived data (cache) or the only copy of some data (primary store).
Step 2
Configure persistence accordingly
For a primary store, enable AOF and/or RDB persistence; a pure cache can often run with persistence disabled for speed.
Step 3
Plan for failover
A primary store needs replication plus Sentinel or Cluster for automatic failover; a cache can tolerate a node simply restarting empty.
Step 4
Match the data structure to the access pattern
Use Redis structures (hashes, sorted sets, streams) deliberately, since Redis lacks general ad hoc querying and multi-key joins.
What Interviewer Expects
- Clear distinction between disposable/rebuildable data and data that exists nowhere else
- Mention of persistence options (RDB/AOF) as the key configuration difference
- Awareness that primary-store use requires replication/failover planning
- Recognition of Redis's querying limitations versus a relational database
Common Mistakes
- Assuming Redis persistence is unnecessary regardless of how it is used
- Treating Redis as a full relational database substitute with joins and ad hoc queries
- Forgetting that a cache miss is cheap but a primary-store data loss is not
- Not planning replication/failover when Redis becomes the source of truth
Best Answer (HR Friendly)
“When Redis is used purely as a cache, losing its data is not a big deal because the application just rebuilds it from the real database on the next request. When Redis is used as the primary store, it becomes the only copy of that data, so you have to turn on persistence, set up replication, and treat any potential data loss as a serious incident, which is a very different operational responsibility.”
Code Example
-- Relational database remains the source of truth
CREATE TABLE Sessions (
session_id CHAR(36) PRIMARY KEY,
user_id INT NOT NULL,
last_active TIMESTAMP NOT NULL
);
-- Redis is used only as a cache in front of it:
-- SET session:{session_id} {user_id} EX 900
-- A cache miss simply falls back to:
SELECT user_id, last_active
FROM Sessions
WHERE session_id = 'a1b2c3d4-...';
-- If this were Redis-as-primary-store instead, there would be
-- no fallback table at all, so persistence (AOF/RDB) and
-- replication become mandatory, not optional.Follow-up Questions
- What is the difference between RDB and AOF persistence in Redis?
- How does Redis Sentinel provide failover for a primary-store deployment?
- What Redis data structures would you use for a leaderboard, and why?
- When would you avoid using Redis as a primary store entirely?
MCQ Practice
1. What is the main operational difference when Redis is used as a primary store instead of a cache?
As a primary store, Redis holds the only copy of the data, so durability and high-availability configuration are required, unlike disposable cache data.
2. Why is losing cached data in Redis generally low-risk?
A cache-aside pattern means a lost cache entry is simply recomputed from the database on the next read, so there is no permanent loss.
3. What is a known limitation of Redis compared to a relational database?
Redis is optimized for fast key-based access to specific structures, not for arbitrary relational queries or joins across many keys.
Flash Cards
Redis as cache vs primary store — key difference? — Cache data is disposable and rebuildable; primary-store data is the only copy and requires durability.
What must be enabled if Redis is a primary store? — Persistence (RDB/AOF), replication, and failover tooling like Sentinel or Cluster.
Why is a cache miss cheap? — The application simply re-fetches the value from the database of record.
What does Redis lack compared to a relational database? — General ad hoc querying and multi-key joins across arbitrary data.