Redis Interview Questions

A curated set of Redis interview questions, ordered roughly from fundamentals to more advanced — the kind you'll actually be asked in real screens and on-sites.

Fundamentals#

Q: Why is Redis so much faster than a typical disk-backed database? Redis keeps its entire dataset in memory, so reads and writes avoid disk I/O entirely on the hot path — RAM access is orders of magnitude faster than even a fast SSD. It also uses simple, purpose-built data structures with a small, direct set of operations per type (a hash table lookup for GET, a linked-list insert for LPUSH) rather than a general-purpose query planner, and its single-threaded command processing avoids the locking overhead a multi-threaded engine needs to coordinate concurrent access to shared structures.

Q: Is data in Redis durable? What happens if the server restarts? By default, Redis is an in-memory store — a restart with no persistence configured loses everything. Redis offers two optional persistence mechanisms: RDB (periodic point-in-time snapshots to disk) and AOF (an append-only log of every write, replayable on startup), which can be used together for a stronger durability guarantee at some cost to write throughput. Even with both enabled, Redis is generally treated as a cache or secondary store rather than a system of record for data that absolutely cannot be lost.

Data type selection#

Q: A product page needs a running view counter. Which Redis data type and command fits, and why? A string with INCR (or INCRBY) — it's an atomic, race-condition-free increment on a single numeric value, exactly what a concurrently-updated counter needs. Using a more complex type here would add nothing; the entire requirement is "increment a number safely under concurrency," which INCR does directly.

Q: You need a real-time leaderboard showing the top 100 players by score, updated constantly. What data type fits, and why not a database table with ORDER BY score LIMIT 100? A sorted set, using ZADD to set/update each player's score and ZRANGE ... WITHSCORES REV to fetch the top N. A sorted set keeps itself ordered by score automatically via an internal skip list, so both updating a score and reading the top N are logarithmic-time operations even with millions of entries — reading "top 100" from a relational table under constant heavy write load would mean re-sorting (or maintaining an index on) a column that's changing constantly, at meaningfully higher latency than an in-memory sorted set built specifically for this.

Caching#

Q: What's the difference between cache-aside and write-through caching, and which is more common? Cache-aside (lazy loading) has the application check the cache first, falling back to the database on a miss and populating the cache afterward — the cache only ever holds data that was actually requested, and the pattern degrades gracefully if the cache is unavailable. Write-through updates the cache and the database together on every write, keeping them in sync immediately but adding latency to every write and caching data regardless of whether it's ever read. Cache-aside is the more common pattern in practice, precisely because of that graceful degradation and lower write overhead.

Q: What is a cache stampede, and how would you prevent one? A cache stampede happens when a popular key expires and many concurrent requests miss the cache at the same instant, all hitting the database simultaneously to repopulate the same value — spiking database load exactly when the cache was meant to protect it. Common mitigations are adding random jitter to TTLs so keys don't all expire in lockstep, and using a short-lived lock key (SET key val EX 5 NX) so only one request recomputes the value while others wait or serve a slightly stale copy.

Messaging#

Q: What's the key limitation of Redis pub/sub compared to Redis Streams? Pub/sub is strictly fire-and-forget — if no client is subscribed at the moment a message is published, it's gone permanently, with no history or replay. Streams persist entries as an append-only log with unique ordered ids, so a consumer that was briefly offline can catch up on everything it missed, and consumer groups provide at-least-once delivery with explicit acknowledgment (XACK) — durability pub/sub simply doesn't offer.

Persistence and scaling#

Q: What's the difference between RDB and AOF persistence, and when would you use each? RDB takes periodic point-in-time binary snapshots of the whole dataset — fast to restore, but anything written since the last snapshot is lost on a crash. AOF logs every write command as it happens and replays the log on startup, bounding data loss to roughly the appendfsync interval (commonly everysec, about one second) at the cost of continuous disk writes. Many production setups enable both together, getting RDB's fast restart time (via the RDB-formatted preamble in a rewritten AOF file) with AOF's tighter durability window.

Q: What's the difference between adding a Redis replica and using Redis Cluster? A replica holds a full copy of the entire dataset, which helps with read scaling and high availability (promoted via Sentinel if the primary fails) but doesn't help if the dataset itself is too large or the write volume too high for one primary to handle. Redis Cluster instead shards the keyspace across multiple nodes — each node holds only a portion of the data — solving horizontal scale for datasets or write throughput that a single instance genuinely can't handle, typically with each shard also replicated internally for its own high availability.

Q: Why do multi-key operations sometimes fail in Redis Cluster but work fine on a single instance? Redis Cluster requires every key involved in a multi-key command to hash to the same slot, since each slot lives on exactly one shard — a command touching keys that land on different shards simply can't execute atomically across them. Hash tags ({...} within a key) fix this deliberately, forcing related keys to hash based on only the tagged portion so they're guaranteed to land on the same slot; this constraint doesn't exist at all on a single, unsharded instance, which is why the same code can work in development and break only once Cluster is introduced.