Top 60 Redis Interview Questions (2026)

Redis is an open-source, in-memory data store that keeps data in RAM for microsecond reads and writes. It works as a cache, a database, and a message broker, and stores more than plain strings: hashes, lists, sets, sorted sets, and streams.

Teams reach for it to cache database results, hold sessions, build leaderboards, rate-limit requests, queue jobs, and push real-time messages. Its speed comes from staying in memory and from a simple single-threaded core that runs one command at a time.

It keeps the working dataset in RAM instead of on disk, so a lookup never waits on a disk seek. That's why Redis answers in microseconds while a disk-backed database answers in milliseconds. Every read and write hits memory first, which is the whole reason Redis is so fast.

The trade-off is cost and size: RAM is pricier and smaller than disk, so your dataset must fit in memory. Redis can still persist to disk in the background for durability, but the live data path stays in RAM.

The core types are strings, hashes, lists, sets, sorted sets, streams, bitmaps, and HyperLogLogs. Each has commands tuned to it, which is why Redis is called a data structure server rather than a key-value store.

Picking the right type is most of the skill: a hash for an object's fields, a sorted set for a leaderboard, a list for a queue, a set for membership tests.

SET stores a string value under a key, and GET reads it back. SET can take options like EX for a time-to-live in seconds and NX to only set if the key doesn't already exist.

These two commands are the backbone of caching: write a value under a key, read it later, and let it expire.

A cache stores the results of slow operations so repeat requests skip the slow path. Redis fits because it reads from memory in microseconds, holds far more than a single app's local cache, and is shared across every app server.

The usual pattern is cache-aside: check Redis first, and on a miss read the database, store the result in Redis with a TTL, then return it. Later reads hit Redis and never touch the database.

You attach a time-to-live to a key, and Redis deletes it automatically once the TTL runs out. Set it with EXPIRE for seconds, PEXPIRE for milliseconds, or inline with SET key value EX 60. The TTL and PTTL commands read how much time a key has left before it disappears.

TTL returns the seconds remaining, or -1 if the key has no expiry, or -2 if the key doesn't exist. Expiry is how caches stay fresh and how sessions and locks clean themselves up.

Two ways together. Lazy expiration: when you touch a key, Redis checks its TTL and deletes it if it's expired. Active expiration: a background job samples random keys with TTLs a few times a second and deletes the expired ones it finds.

So an expired key can sit in memory briefly until it's accessed or sampled. That's fine for correctness because Redis never serves an expired key, but it's why memory doesn't drop the instant a TTL passes.

Redis is in-memory and key-based; MySQL is disk-based and query-based. Redis gives you microsecond access to values you fetch by key, with no joins, no SQL, and no complex query planner. MySQL gives you rich queries, relationships, and durability by default.

They usually work together: MySQL as the system of record, Redis as the fast layer in front of it. Redis isn't a replacement for a relational database; it removes load from one.

Strings hold more than text. INCR and DECR treat the value as an integer and change it atomically, which makes counters trivial. APPEND adds to the end, GETRANGE and SETRANGE work on substrings, and STRLEN gives the length.

Because INCR is atomic, many clients can increment the same counter with no race condition and no locking.

Use a hash to store an object with named fields under one key, like a user with a name, email, and role all grouped together. HSET writes one or more fields, HGET reads a single field, HGETALL reads them all, and HDEL removes a field without touching the rest.

It beats storing a JSON string when you want to read or update single fields without fetching and rewriting the whole object, and it uses memory efficiently for small objects.

A list is an ordered sequence of strings you push and pop from either end. LPUSH and RPUSH add, LPOP and RPOP remove. That makes it a natural queue (push one end, pop the other) or a recent-activity timeline.

BLPOP and BRPOP block until an item arrives, which turns a list into a simple work queue between producers and consumers.

A set is an unordered collection of unique strings, so it enforces uniqueness for you. SADD adds members and silently drops duplicates, SISMEMBER checks membership in constant time, SCARD counts the members, and SREM removes them. There's no ordering, just fast membership and set math.

Sets fit uniqueness and relationships: tags on an item, unique visitors today, or set operations like intersection (SINTER) to find common elements between two groups.

A sorted set stores unique members, each paired with a numeric score, and keeps them ordered by that score automatically. ZADD sets a member's score, ZRANGE reads members low to high, ZREVRANGE reads them high to low, and ZRANK tells you a member's position in the ordering.

That maintained ordering is what makes leaderboards, priority queues, and time-ranged data easy: the ranking updates itself, and rank lookups and range queries stay fast.

KEYS pattern scans every key in the database in one blocking pass. Because Redis runs commands one at a time, a KEYS over millions of keys freezes the whole server until it finishes, stalling every other client.

Use SCAN instead. It walks the keyspace in small batches with a cursor, so it never blocks Redis for long. KEYS is fine only for debugging on a tiny local dataset.

EXISTS returns 1 if a key is present and 0 if not, and it accepts several keys to count how many exist. DEL removes one or more keys. UNLINK does the same but frees the memory in a background thread, which is safer for large values.

For a big key, prefer UNLINK so the deletion doesn't block the single command loop while Redis reclaims the memory.

The core command loop is single-threaded: Redis runs one command from start to finish before it picks up the next. That design is why every individual command is atomic and you rarely need locks for single operations, since nothing can interleave halfway through a command.

It also means one slow command, a big KEYS or a huge sort, blocks everyone. Modern Redis uses extra threads for network I/O and background tasks like UNLINK, but command execution stays serialized.

Atomic means a command runs completely or not at all, with nothing interleaving in the middle. Because Redis executes one command at a time, operations like INCR, LPUSH, and SETNX finish fully before any other client's command starts.

That's why you can build a counter or a simple lock without a mutex: INCR from a thousand clients can't lose an update, and SET key val NX either sets the key or fails cleanly.

Not necessarily. Redis is in-memory, but it can persist to disk so it reloads data on restart. RDB writes point-in-time snapshots on a schedule; AOF logs every write and replays them on startup. You can run either, both, or neither.

With no persistence, a restart starts empty, which is fine for a pure cache. With AOF, you lose at most about a second of writes. The choice is a durability-versus-performance trade-off.

Redis listens on TCP port 6379 by default. You connect with the redis-cli command-line client, or with a client library in your language, pointing it at the host and port. A password or ACL user is added when the server requires authentication, which any production instance should.

Running redis-cli PING should return PONG on a healthy server, which is the quickest way to confirm the connection works before you send real commands.

A single Redis instance has numbered logical databases, 0 to 15 by default, and SELECT switches the current connection between them. Keys in one database are invisible to another, so it looks like a quick way to separate concerns on one server without spinning up more instances.

In practice most teams avoid them for separation because they share the same process, memory, and CPU, and Redis Cluster supports only database 0. Prefer key prefixes or separate instances for real isolation.

MSET writes several key-value pairs in one atomic command, and MGET reads several keys in a single round trip, returning nil for any that are missing. Both cut network overhead compared with looping single GETs and SETs, and MSET applies all its writes together so no other client sees a half-finished batch.

Fewer round trips is a real speedup: one MGET of 100 keys beats 100 separate GETs because you pay the network latency once instead of a hundred times.

Use a consistent, colon-separated convention that reads like a path: object:id:field, for example user:1042:profile or session:abc123. That structure groups related keys together, makes SCAN patterns predictable, and keeps a shared instance readable when several apps or teams write to the same Redis.

Keep keys reasonably short since every one lives in memory, and avoid spaces. There are no real folders in Redis; the colons are pure convention, but the whole ecosystem follows it.

The big ones are caching database results, storing user sessions, and rate limiting API requests. Beyond those, teams build leaderboards with sorted sets, queues and background jobs with lists or streams, real-time counters with INCR, and pub/sub notifications for live updates like chat or presence.

The thread through all of them is speed on data you'd otherwise recompute or fetch from a slower store. If a value is read far more than it changes, or needs to be counted or ranked in real time, it's a Redis candidate.

FLUSHDB deletes every key in the currently selected database, while FLUSHALL deletes every key in every database on the whole instance. Both are immediate and irreversible, and by default they block until the wipe finishes, though an ASYNC option lets Redis reclaim the memory in the background.

These are dangerous in production, since a stray FLUSHALL wipes the entire instance. Many teams rename or disable them in the config so nobody runs them by accident.

RDB saves a compact point-in-time snapshot of the whole dataset on a schedule, forked in the background. It restarts fast and is small, but a crash loses everything since the last snapshot. AOF logs every write command and replays the log on startup, so it loses far less, at the cost of a larger file and slightly slower writes.

Many production setups run both: AOF for durability, RDB for fast restores and backups. The choice comes down to how much data loss you can tolerate on a crash.

The AOF log grows forever because it records every write, including ones later overwritten. AOF rewrite compacts it: Redis forks and writes a new, minimal log that reproduces the current dataset with the fewest commands, then swaps it in.

Without rewrite, the file would balloon and startup replay would crawl. Redis triggers it automatically when the file grows past a configured percentage, or you can force it with BGREWRITEAOF.

When memory hits maxmemory, Redis evicts keys according to a policy. The common ones: noeviction (reject writes), allkeys-lru (evict least recently used from all keys), volatile-lru (only keys with a TTL), allkeys-lfu and volatile-lfu (least frequently used), allkeys-random, volatile-random, and volatile-ttl (soonest to expire).

For a pure cache, allkeys-lru or allkeys-lfu is usual. If Redis holds data you can't lose, noeviction with alerting is safer so you notice before you run out of room.

LRU (least recently used) evicts whatever hasn't been touched for the longest time, so it tracks recency of access. LFU (least frequently used) evicts whatever is accessed the least often overall, using a per-key frequency counter that decays over time so old popularity doesn't count forever.

LFU handles skewed traffic better: a key hit constantly stays cached even after a brief gap, whereas pure LRU might drop it after one quiet stretch. LFU became available in Redis 4.0.

In cache-aside, the application owns the cache: read Redis first, and on a miss read the database, write the result to Redis with a TTL, then return it. Writes update the database and either delete or update the cached key.

The main risk is stale data: if the database changes but the cached key isn't invalidated, readers see old values until the TTL expires. That's why invalidation on write, plus a sane TTL as a safety net, matters.

Write-through: the app writes to the cache, and the cache synchronously writes to the database, so both stay consistent but every write pays the database latency. Write-behind (write-back): the app writes to the cache, which returns immediately and flushes to the database asynchronously, which is faster but risks losing buffered writes on a crash.

Cache-aside stays the most common because it's simple and keeps the database as the source of truth. Write-through and write-behind usually need a cache layer that integrates with the database, which Redis doesn't do on its own.

A cache stampede (thundering herd) happens when a hot key expires and many concurrent requests all miss at once, so they all hit the database to rebuild the same value together, spiking load right when the cache should be protecting it.

Fixes: a short lock so only one request rebuilds while others wait or serve stale, recomputing slightly before expiry (early recompute), and adding random jitter to TTLs so keys don't all expire at the same instant.

Cache penetration is when requests keep asking for keys that don't exist anywhere, so every single request misses the cache and falls through to the database. Attackers can exploit it deliberately by querying random non-existent IDs, and legitimate bugs can trigger it too, both pushing full load onto the backing store.

Two defenses: cache the negative result as well, storing a short-lived null marker so repeat misses stop at Redis, and put a Bloom filter in front to reject keys that definitely don't exist before touching the database.

MULTI starts a transaction, commands typed after it are queued instead of run immediately, and EXEC then runs the whole queue as one atomic unit with no other client's commands interleaved in the middle. DISCARD throws the queued commands away without running them if you change your mind.

Redis transactions aren't like SQL: there's no rollback. If a queued command fails at runtime, the others still run. They guarantee isolation and atomic execution, not all-or-nothing on logic errors.

WATCH marks one or more keys for optimistic locking before a transaction begins. If any watched key changes between the WATCH and the EXEC, the EXEC aborts and returns nil instead of running, so your client retries. It's a check-and-set pattern that gives safety without holding a blocking lock on the key.

This is how you do a safe read-modify-write across keys: WATCH the key, read it, MULTI your change, EXEC, and loop if EXEC failed because someone else got there first.

Publishers send messages to named channels with PUBLISH, and subscribers receive messages from any channel they SUBSCRIBE to. Redis routes each published message to every client currently subscribed to that channel, and PSUBSCRIBE lets a subscriber match many channels at once by pattern, like news.* for everything under news.

It's fire-and-forget: if no one is subscribed when a message is published, the message is gone. There's no history and no acknowledgment, so pub/sub fits live notifications, not durable messaging.

A stream is an append-only log of entries with IDs, added by XADD and read by XREAD or XRANGE. Unlike pub/sub, a stream keeps its history, so consumers can read past messages, and consumer groups let multiple workers split the load with acknowledgment and retry.

Use pub/sub for ephemeral live signals where losing a message is fine. Use streams when you need durable, replayable messaging with at-least-once delivery, like a job queue or an event log.

One primary handles writes and streams its changes to one or more replicas, which serve reads and stay ready to take over. Replication is asynchronous: the primary doesn't wait for replicas to confirm, so a replica can trail by a moment.

This scales reads and adds redundancy, but because it's async, a primary can acknowledge a write and crash before the replica gets it, which is a small window of possible loss to name when asked about consistency.

Sentinel provides high availability for a primary-replica setup. A group of Sentinel processes monitors the primary and its replicas, agrees by quorum when the primary is actually down (not just slow), automatically promotes a healthy replica to primary, and then tells clients about the new address so traffic follows the failover.

It gives you automatic failover without sharding: the dataset still fits on one primary, but you're covered when that node dies. For horizontal scaling of data across nodes, you need Redis Cluster instead.

Redis Cluster splits the keyspace into 16384 hash slots. Each key's slot is CRC16(key) modulo 16384, and every node owns a range of slots. That spreads data across nodes so the dataset can exceed one machine's memory.

A multi-key command works only when all its keys live in the same slot. Hash tags, a substring in braces like {user1042}, force related keys into the same slot so you can run those commands.

Pipelining sends many commands at once without waiting for each reply, then reads all the replies together. It slashes latency by paying the network round trip once instead of per command; it's a speed optimization, not an atomicity guarantee.

A transaction (MULTI/EXEC) is about atomic execution: the queued commands run together with nothing interleaved. Pipelining is about throughput: the commands are still independent and other clients' commands can run among them.

The basic lock is SET key token NX EX ttl: NX sets it only if absent (so only one client wins) and EX gives it an expiry so a crashed holder doesn't block forever. To release, delete the key only if the token still matches, done with a small Lua script for atomicity.

For a single instance that's enough for most needs. Across multiple independent Redis nodes, the Redlock algorithm exists but is debated; for real correctness-critical locking, many engineers reach for a system built for consensus instead.

A simple fixed-window limiter: key on the user plus the current time bucket, INCR it, set an expiry the first time, and reject once the count passes the limit. INCR is atomic, so concurrent requests count correctly.

Fixed windows allow bursts at the boundary. A sliding-window log with a sorted set (store timestamps, trim old ones, count what's left) or a token bucket in Lua smooths that out when you need precision.

Set TTLs so stale data leaves, pick memory-efficient types (small hashes and sorted sets use compact encodings), keep keys and values short, and use MEMORY USAGE and the INFO memory section to find the heavy keys.

Watch for big collections: a single list or hash with millions of elements is a big key that hurts latency and memory. Shard it, or use HyperLogLog for approximate counts and bitmaps for flags to save space.

EVAL runs a Lua script on the server, and the whole script executes atomically, one shot, with nothing interleaving. That lets you do read-then-write logic (check a value, decide, update) with no race and one round trip instead of several.

It's how you build atomic operations Redis doesn't offer natively, like a safe lock release or a token-bucket rate limiter. Keep scripts short, since a long script blocks the single-threaded server the whole time it runs.

A single Redis instance is strongly consistent for its own commands because they run serially. Once you add replication it becomes eventually consistent: replication is asynchronous, so a replica can serve a slightly older value than the primary just wrote.

The sharp edge is failover. A primary can acknowledge a write and die before the replica receives it; the promoted replica then never had that write. WAIT can block until N replicas confirm, narrowing but not closing the window. Redis trades strict durability for speed by design.

A big key (a huge list, set, or hash) makes any operation on it slow, and because Redis is single-threaded, that one slow operation stalls every other client. Deleting it with DEL can block; use UNLINK. A hot key (one key getting a huge share of traffic) can saturate the one node that owns it, and in a cluster it can't be spread because it's a single slot.

Fixes: shard a big collection across many keys, use UNLINK for large deletions, and for a hot key add a local per-app cache, replicate reads, or split the value across keys so the load spreads.

Choose by the constraint. If your dataset fits in one node's memory and you only need automatic failover, Sentinel is simpler: it monitors and promotes replicas, no resharding, and full multi-key command support. If the dataset or write throughput exceeds one node, you need Cluster to shard across nodes.

Cluster's cost is real: multi-key commands work only within a slot (needing hash tags), some operations are restricted, and clients must be cluster-aware. So don't reach for Cluster until single-node plus replicas genuinely can't hold the load.

Both snapshotting and AOF rewrite fork a child process. Fork uses copy-on-write, so it's cheap at first, but if the parent keeps writing heavily, the OS copies more memory pages and the fork can briefly spike memory toward double the dataset and stall the main process. On a memory-tight box this can cause a fork failure or an OOM kill.

Mitigations: keep enough headroom above the dataset size, schedule heavy snapshots off-peak, tune AOF rewrite thresholds, and watch latest_fork_usec in INFO. This is exactly the kind of production scar senior interviews probe.

Anything O(n) over a large keyspace or collection is dangerous on the single thread: KEYS, a full SMEMBERS or LRANGE 0 -1 on a giant collection, a big SORT, FLUSHALL, and DEL on a huge key. Each holds the command loop until it finishes, stalling everyone.

Avoid them with the cursor-based iterators (SCAN, HSCAN, SSCAN, ZSCAN), UNLINK instead of DEL, ranged reads instead of full dumps, and pagination. Watch the slow log (SLOWLOG GET) to catch offenders in production.

Pick a strategy and accept its trade-off. TTL-only tolerates staleness up to the TTL, simplest but loosest. Invalidate-on-write deletes or updates the key when the database changes, tighter but needs every write path to remember. Change-data-capture streams database changes to a consumer that updates Redis, the most reliable at scale but the most moving parts.

The nuance: prefer deleting the key over updating it on write, because two concurrent writers updating the cache can race and leave a stale value, while delete-then-repopulate-on-read avoids that ordering problem.

Redis is in-memory and optimized for microsecond access to a dataset that fits in RAM, with rich data structures. Cassandra is a disk-based, distributed wide-column store built for enormous datasets, high write throughput, and tunable consistency across many nodes and data centers.

Reach for Redis when latency and data structures matter and the working set fits in memory: caching, sessions, leaderboards, queues. Reach for Cassandra when you need to store terabytes durably with linear write scaling. They often coexist: Cassandra as the durable store, Redis as the hot layer in front.

Replicas don't independently expire keys. The primary decides when a key expires and sends an explicit DEL (or UNLINK) to replicas, so they stay consistent with the primary rather than each deleting on its own clock.

This matters because a replica might still hold a logically expired key until the primary's delete arrives. Modern Redis guards against a replica returning such a stale key on reads, but the model is worth knowing: expiry is authoritative on the primary, propagated down.

Memory (used_memory versus maxmemory and the fragmentation ratio), cache hit rate (keyspace_hits over hits plus misses), evicted and expired key counts, connected clients and blocked clients, replication lag, latency and slow-log entries, and fork timing (latest_fork_usec).

A falling hit rate, rising evictions, or climbing memory usually means the cache is undersized or a TTL policy is wrong. INFO exposes most of this, and Redis's built-in latency monitor and SLOWLOG pinpoint stalls.

Opening a TCP connection per operation is wasteful, so clients pool connections and reuse them. Because the server is single-threaded, throughput comes from keeping the pipe busy: pipelining commands, reusing connections, and avoiding a flood of short-lived connections that spend the server's time on setup and teardown.

Watch connected_clients and the maxclients limit. A connection leak (clients opened and never returned to the pool) slowly exhausts the limit and starts refusing new connections, a classic production incident.

Modules extend Redis with new commands and data types written in C against its module API. RedisJSON adds native JSON with path queries, RediSearch adds secondary indexing and full-text search, RedisBloom adds probabilistic structures like Bloom filters and count-min sketch, and RedisTimeSeries adds time-series storage.

Reach for a module when you'd otherwise contort a core type to fake the feature: secondary search over values, JSON path updates, or approximate membership. The trade-off is an added dependency and version and licensing considerations to check before you commit.

Three tools, in order of power. MULTI/EXEC queues commands to run together with no interleaving but no rollback. WATCH adds optimistic locking so EXEC aborts if a watched key changed. A Lua script (EVAL) runs read-and-write logic atomically in one shot, which is the strongest for check-then-act.

In a cluster, all the keys must live in the same hash slot for any of these, which is what hash tags are for. If your keys can't share a slot, you can't do it atomically in Redis and need to rethink the data layout.

Store each session under a key like session:<id> holding a hash or serialized blob, with a TTL matching the session timeout that you refresh on each request (a sliding expiry). Keep the payload small; store an ID and look up heavy data from the database. Use replication or Cluster for availability so a node loss doesn't log everyone out.

Decide the durability stance up front: pure cache means a total loss logs users out, which is usually acceptable; if not, enable AOF. Also plan for a stampede on the login path and invalidate sessions on logout by deleting the key.

Work from observation to cause. Check SLOWLOG for slow commands (a stray KEYS or big-key op), LATENCY LATEST and LATENCY DOCTOR for Redis's own diagnosis, and INFO for fork timing and memory pressure. Correlate spikes with RDB saves or AOF rewrites (fork stalls), swapping (Redis paged to disk destroys latency), and eviction storms when memory is tight.

Common culprits: an O(n) command on a big key, a fork during a snapshot, the box swapping, or network saturation. The method matters more than any single tool: observe, correlate with events, hypothesize, verify, fix.

Never expose it to the public internet: bind to private interfaces, use a firewall, and enable TLS for encryption in transit. Require authentication with ACLs (Redis 6+) so each client has a user with only the commands and key patterns it needs, instead of one shared password. Rename or disable dangerous commands (FLUSHALL, CONFIG, KEYS).

The most common breach is an open, unauthenticated Redis reachable from the internet, where an attacker can read everything or use CONFIG to write files. Defense in depth: network isolation, TLS, ACLs, and least privilege.

When the dataset can't fit in memory affordably, when you need rich queries, joins, or ad-hoc reporting (that's a relational or analytical database), when you need strong durability with zero tolerance for the async-replication loss window, or when you need complex transactions with rollback.

Redis is a fast layer and a data structure server, not a system of record for everything. Naming its limits, and picking it for the jobs it's built for, is the judgment senior interviewers are checking for.