Redis Interview Questions and Answers for Backend Engineers

Redis interview questions usually mix data-structure trivia with real production concerns: persistence, eviction, replication, and what happens when a cache becomes a system of record by accident. This guide walks through the questions hiring teams ask most often, with answers you can explain out loud—not just recite.

What Redis is (and is not)

Redis is an in-memory data store that supports rich structures (strings, hashes, lists, sets, sorted sets, streams, and more). It is often used as a cache, session store, rate limiter, pub/sub bus, or ** lightweight job queue**.

It is not a replacement for a relational database when you need complex joins, strong transactional guarantees across many entities, or cheap storage for cold data. Teams that treat Redis as primary storage without a plan for durability and capacity planning learn painful lessons in outages.

If an interviewer opens with “Why Redis?”, a strong answer names latency, simple data models, and atomic primitives—then acknowledges tradeoffs around memory cost and operational complexity.

Core data types and when to use them

Strings — Counters (INCR), distributed locks with SET key value NX EX ttl, simple key-value flags.

Hashes — Fielded objects (user profile snippets) where you want partial updates without serializing JSON on every read.

Lists — Queues and timelines; know that blocking pops (BLPOP) underpin simple worker patterns.

Sets — Unique membership, tags, “users online” with SADD / SISMEMBER.

Sorted sets (ZSET) — Leaderboards and priority queues; scores must be numeric; ties break lexicographically on member strings.

Streams — Append-only logs with consumer groups; useful for event fan-out when you outgrow lists.

Interview tip: pair each structure with one concrete use case from your experience, even if it was a side project.

Common Redis interview questions and answers

How does Redis persist data?

Redis is in-memory first. RDB snapshots point-in-time files on a schedule or after N changes. AOF logs every write (with configurable fsync policy) for finer recovery at the cost of disk I/O and file size. Many teams enable both: RDB for fast restarts, AOF for durability. You should mention appendfsync everysec as a common compromise and that neither mode is a substitute for backups off the primary.

What happens when memory is full?

If maxmemory is set and a policy is configured, Redis evicts keys according to the policy (allkeys-lru, volatile-lru, allkeys-lfu, etc.) or returns errors on writes (noeviction). Interviewers want to hear that you size memory, monitor eviction rate, and avoid caching without TTLs when policy is LRU.

Explain TTL and expiration

Keys can have EXPIRE or be set with SET key value EX seconds. Expiration is lazy (checked on access) and active (sampled periodically). Do not assume sub-second precision for all workloads; design idempotent consumers if keys can disappear mid-flow.

What is single-threaded execution?

The main command path is single-threaded, which avoids lock contention and keeps latency predictable. Slow commands (KEYS, huge SMEMBERS, unbounded LRANGE) block everything—use SCAN, paginate, or redesign. Redis 6+ adds I/O threads for networking, but command execution semantics still matter for hot keys.

How do replication and failover work?

Primary-replica replication is asynchronous by default. Replicas can serve reads if you accept stale reads. Redis Sentinel monitors primaries and promotes replicas. Redis Cluster shards keyspace across nodes with hash slots. Know the CAP tradeoff: a promoted replica may have lost the last writes from the old primary.

Compare Redis transactions and pipelines

Pipeline batches commands to reduce round trips; it is not atomic unless you use MULTI/EXEC. Transactions queue commands but do not roll back on failure mid-exec the way SQL does—errors happen at queue time vs exec time differently. For true atomic compare-and-set, WATCH optimistic locking or Lua scripts are common patterns.

How would you implement a rate limiter?

Classic pattern: INCR with EXPIRE on first increment, or a sliding window with a sorted set of timestamps. Mention token bucket in Lua for smoother bursts. Discuss key naming (ratelimit:{user}:{minute}) and clock skew across app servers.

Distributed locks with Redis

Use SET lock_key token NX EX ttl, run work, delete with a Lua script that checks the token matches before delete (avoid deleting someone else’s lock after slow GC). Redlock is controversial—interviewers often want you to acknowledge fencing tokens and that locks alone do not solve every consistency problem.

Cache stampede / thundering herd

When a hot key expires, many requests miss at once. Mitigations: probabilistic early expiration, single-flight (one recomputes, others wait), ** stale-while-revalidate**, or a short-lived mutex key around rebuild.

Big-O for common operations

Most single-key reads/writes are O(1). LRANGE is O(N) in the number of elements returned. ZADD is O(log N)**. Showing you think about hot key size and command complexity signals seniority.

Scenario questions

“Session store in Redis—what breaks?”
Sticky sessions without TTL leak memory. Large session blobs inflate network I/O. Rolling deploys without shared Redis log users out. Serialization format changes invalidate sessions.

“Cache aside vs read through”
Cache aside: app reads cache, on miss loads DB and sets cache. Read through: cache layer loads DB transparently. Write through / write behind affect consistency—name which your team used and what inconsistency window you accepted.

“How do you find hot keys?”
redis-cli --hotkeys (with warnings in production), latency doctor, monitor command rates, client-side metrics tagged by key prefix.

Operations and security talking points

• Bind to private networks; require TLS and ACL users in production.
• Disable or rename dangerous commands (FLUSHALL, CONFIG) for multi-tenant environments.
• Run MEMORY DOCTOR and track used_memory_rss vs used_memory to catch fragmentation.
• Plan version upgrades (ACL, streams, modules) and test failover drills.

Mistakes candidates make

Reciting every command flag without tying to a story. Claiming Redis is “always faster than Postgres” without mentioning workload shape. Ignoring eviction when discussing caches. Forgetting that replication lag affects read-your-writes guarantees.

FAQ

Is Redis only a cache?
No, but caching is the most common entry point. It also powers rankings, pub/sub, lightweight queues, and rate limiting.

Should I use Redis Cluster for a small app?
Usually not until single-node memory or CPU is exhausted and you have operational appetite for slot migrations and client routing.

What is the difference between LRU and LFU eviction?
LRU approximates least recently used keys; LFU approximates least frequently used. LFU resists one-time scans polluting the cache.

How do Redis and Memcached differ?
Redis offers richer types, persistence options, and replication; Memcached is simpler multi-threaded RAM caching. Many greenfield systems pick Redis for flexibility.

Walking into a Redis interview with data model choices, durability/eviction awareness, and two war stories (even from labs) beats memorizing every subcommand. Use this list to practice explaining tradeoffs aloud until the answers feel like engineering judgment, not flash cards.

Modules and Redis Stack (brief)

RedisJSON, RediSearch, and RedisTimeSeries extend the core engine with module APIs. Interviewers at companies using Redis Stack may ask how you would index JSON documents or run secondary queries. You do not need implementation depth unless the role says so—acknowledge that modules add operational packaging considerations (memory overhead, upgrade cadence).

Memory optimization talking points

• Prefer compact encodings for small hashes and lists; shard hot keys before a single key holds millions of members.
• Compress repetitive JSON at the application layer when values dominate RAM usage.
• Use UNLINK instead of DEL for large key deletes to avoid blocking the event loop on big objects.

Closing preparation checklist

Before your interview, rehearse answers to: persistence modes, eviction policies, replication lag, SET NX locks, and cache-aside vs read-through. Bring one metric you would monitor (evicted_keys, instantaneous_ops_per_sec, command latency p99) and one incident you would prevent (unbounded KEYS * in production). That structure keeps Redis questions grounded in operability, which is what hiring managers actually optimize for.