Redis and Caching Interview Questions

At 4+ years you are not asked "what is Redis?". You are asked "your product page is slow, what do you cache, what is the TTL, how does it get updated, and what happens when Redis is down?". This lesson gives you the words and the answers. It also covers the Redis features that come up most: data types, saving data to disk, eviction, rate limits, sessions, messaging and locks. Every code sample was run against a real Redis server (7.0) from Node 22, with ioredis 6.0.0 and redis (node-redis) 6.3.0.

Related lessons: the larger design view is in Design Problems, Lesson 01 (URL shortener) and Lesson 02 (rate limiter). Browser and CDN caching is in Browser, Lesson 05. Next.js caching is in Next.js interview questions. Session auth is in Backend, Lesson 06.

Words used in this lesson

• A cache is a small, fast store that keeps answers you already got, so you do not ask the slow source again. Like a notebook on your desk: you do not walk to the library for the same fact twice.
• Redis is a data store that keeps its data in memory (RAM), so reads and writes take well under a millisecond on the server. Many app servers can share it. It is a server you connect to over the network, not a library inside your process.
• A key is the name of a value in Redis (such as user:42). A value is the data under that name. Redis keys are strings.
• A hit is a read that found the value in the cache. A miss is a read that did not. The hit rate is hits divided by all reads.
• A TTL (time to live) is the number of seconds a key may live before Redis deletes it.
• Eviction is Redis deleting keys to make room when memory is full. Expiry is Redis deleting a key because its TTL ended. They are different: one is about space, the other about time.
• Invalidation is removing or replacing a cached value because the real data changed.
• A cache stampede (also called a thundering herd) is what happens when a popular key expires and many requests miss at the same moment. They all go to the database together.
• Atomic means a step that cannot be cut in half. No other command can run in the middle. Redis runs one command at a time, so every single command is atomic.
• Persistence means saving data to disk, so it survives a restart. RDB and AOF are the two ways (below).
• Idempotent means doing it twice has the same effect as once.

Why a cache, and what it costs

A database read may take 5 to 50 ms and uses a connection. A Redis read inside the same data centre takes roughly 0.5 ms. If 90 of every 100 reads are hits, the database sees only 10 percent of the load. That is the whole idea.

The cost is that you now have two copies of the truth. Two copies can disagree. Almost every cache question is really "how long may they disagree, and who pays when they do?".

The four caching patterns

Cache-aside is the one you will use. In Node there is no built-in read-through, so you write a small helper. The code below also adds three habits I always want: a TTL with a small random extra time (jitter), a short cached "not found" answer, and JSON in and out.

import Redis from "ioredis";const redis = new Redis(); // localhost:6379async function getUser(id) {  const key = `user:${id}`;  const hit = await redis.get(key);  if (hit !== null) return JSON.parse(hit);        // the string "null" is a cached "not found"  const row = await db.getUser(id);                // slow path  const ttl = row ? 300 + Math.floor(Math.random() * 60) : 30; // jitter; short TTL for "not found"  await redis.set(key, JSON.stringify(row), "EX", ttl);  return row;}

I ran this. The second call for the same id did not reach the database, and TTL showed 313 seconds for a user and 30 seconds for the cached "not found".

Write-behind needs care, because if Redis dies before the background writer runs, you lose writes. A safer shape uses a Redis stream (below) as a durable queue between the cache and the database:

async function writeBehind(id, value) {  await redis.set(`u:${id}`, JSON.stringify(value));  await redis.xadd("db-writes", "MAXLEN", "~", 100000, "*", "id", String(id), "json", JSON.stringify(value));  // a worker reads "db-writes" with a consumer group and updates the database}

What to cache (and what not to)

• Good: data that is read much more than it is written, costs a lot to build (joins, aggregations, calls to other services), and can be a little stale. Examples: product pages, public profiles, config, permissions, rendered fragments.
• Bad: data that must be exact every time (account balance, stock for the last item), data that is different for every user and is read once, and very large values.
• Key names should say what they are and include everything that changes the answer: product:42:en:v3. If the language changes the result, language must be in the key. Forgetting this is a classic bug: one user sees another user's data.

TTL and invalidation

TTL: the safety net

A TTL makes every wrong value fix itself eventually. Choose it by asking "how stale may this be?". A news home page: 30 seconds. A product description: 5 to 15 minutes. A permission list: very short, or invalidate on change.

Facts worth knowing, all tested:

• TTL key returns -1 if the key exists with no expiry, and -2 if the key does not exist.
• A plain SET key value on an existing key removes its TTL (the TTL became -1 in my test). Use KEEPTTL to keep it, or set the TTL again.
• Redis deletes expired keys in two ways: when a client touches the key (passive), and by regularly testing a few random keys that have a TTL (active). So an expired key may use memory for a short while, but you will never read it.
• Add jitter (a small random amount) to TTLs. If you fill 100,000 keys at the same second with the same TTL, they all expire at the same second. This is called a cache avalanche.

Three ways to invalidate

1. Delete on write (most common). After the database write succeeds, DEL the key. The next read fills it again.
2. Update on write (write-through). Faster reads after the write, but you must build the exact same value the reader would, in two places.
3. Version in the key. Keep a counter ver:products. Put it in the key: products:v7:42. To clear all products, INCR ver:products. Old keys are never read again, and they expire by TTL. I tested this: after the INCR, the old key returned null.

Stampede (thundering herd)

A hot key expires. In the next 50 ms, 500 requests miss. All 500 run the same slow query. The database slows down, the queries take longer, so even more requests pile up. This can take a site down.

I tested the simple case: 50 concurrent requests for one missing key caused 50 database calls.

Ways to stop it, from simple to strong:

Here is the lock version. I ran it with 5 separate Node processes asking for the same missing key at the same time, and the database was called once.

import { randomUUID } from "node:crypto";const RELEASE = `if redis.call("get",KEYS[1])==ARGV[1] then return redis.call("del",KEYS[1]) end return 0`;const sleep = (ms) => new Promise((r) => setTimeout(r, ms));async function cached(key, ttlSec, load) {  const hit = await redis.get(key);  if (hit !== null) return JSON.parse(hit);  const token = randomUUID();  const gotLock = await redis.set(`lock:${key}`, token, "PX", 10_000, "NX");  if (gotLock !== "OK") {    for (let i = 0; i < 20; i++) {               // someone else is loading: wait, then re-read      await sleep(25);      const again = await redis.get(key);      if (again !== null) return JSON.parse(again);    }  }  try {    const value = await load();                  // if we waited too long, we load anyway    await redis.set(key, JSON.stringify(value), "EX", ttlSec);    return value;  } finally {    if (gotLock === "OK") await redis.eval(RELEASE, 1, `lock:${key}`, token);  }}

Probabilistic early refresh (the "XFetch" idea): with ttlLeft and the time a load takes (delta), refresh early when -delta * Math.log(Math.random()) >= ttlLeft. In my run, with 2 seconds left and a 100 ms load, nobody refreshed. With 100 ms left, about 36 percent of calls refreshed, so one of the first requests renews the key before it dies.

Two related problems with similar names:

• Cache penetration: requests for keys that never exist (/user/-1) always miss and hit the database. Fix: cache the "not found" answer for a short time, and validate the input.
• Cache avalanche: many keys expire together, or Redis restarts empty. Fix: jitter, and protect the database with a limit on concurrent loads.

Redis data types

A Redis value is not only a string. Choose the type that matches the question you will ask.

All of these were run in my tests. Notes that interviewers like:

• A hash lets you change one field without reading and rewriting a whole JSON string. A JSON string is simpler when you always read the whole thing.
• Sorted set vs list for a queue: a list is a plain FIFO queue. A sorted set lets you pick by score (time, priority).
• HyperLogLog counts unique items in about 12 KB per key, with a small error (under 1 percent), no matter how many items. It cannot list them.
• Big keys (a hash with 5 million fields) and hot keys (one key getting most traffic) are common production problems, because one command on a big key blocks everyone else.

Never use KEYS in production

KEYS user:* walks the whole keyspace in one command. While it runs, every other client waits. Use SCAN, which returns a few keys at a time and a cursor to continue. With ioredis, scanStream does the looping for you:

let count = 0;for await (const keys of redis.scanStream({ match: "tmp:*", count: 10 })) count += keys.length;

SCAN can return a key twice and may miss keys added while it runs, so your code must allow duplicates.

Saving data to disk: RDB and AOF

Redis keeps data in memory, so a restart loses everything unless you turn on persistence. There are two methods, and you can use both.

• fork is an operating system call that makes a copy of a running process. Redis uses it so the child can write the file while the parent keeps serving clients. On a big dataset, the fork itself can pause Redis for a short time.
• appendfsync has three settings: always (safe, slow), everysec (the default: fast, loses up to about a second), no (the operating system decides).
• In the default config of the server I tested, save 3600 1 300 100 60 10000 is on (RDB snapshots), and appendonly is no.
• If both are on, Redis uses the AOF at restart, because it is the most complete.
• The Redis docs say: use both if you want data safety similar to a normal database; use RDB alone if losing a few minutes is fine; use no persistence for a pure cache.

Eviction: what happens when memory is full

Set a memory limit with maxmemory (for example maxmemory 100mb). By default there is no limit (0) on 64-bit systems, and the default policy maxmemory-policy is noeviction: when full, writes fail with OOM command not allowed when used memory > 'maxmemory' while reads still work. I saw this error in my test.

• LRU (least recently used) removes what has not been touched for the longest time. LFU (least frequently used) removes what is touched least often.
• Redis does not track exact LRU. It samples a few keys (maxmemory-samples, default 5) and removes the best candidate among them. This saves memory and is close enough in practice.
• volatile-* policies behave like noeviction when no key has a TTL. I confirmed this: with volatile-lru and keys without TTLs, writes failed.
• For a cache, the Redis docs suggest allkeys-lru as a good default. For one instance that mixes cache keys and must-keep keys, volatile-* is possible, but the docs advise two separate instances instead.

I ran a small test with a 3 MB limit: 20 hot keys read often, then 2,400 keys written once each. With allkeys-lru only 1 of the 20 hot keys survived; with allkeys-lfu all 20 survived. So a one-time scan can wash out an LRU cache, while LFU protects keys that are used a lot.

To see if your policy works, read INFO stats: hit rate is keyspace_hits / (keyspace_hits + keyspace_misses), and evicted_keys tells you how many keys were removed for space.

Common uses: rate limits, sessions, queues

Rate limiting

A rate limiter counts requests per user (or IP) in a time window and rejects the extra ones. The first idea is INCR plus EXPIRE:

const c = await redis.incr(`rl:${ip}`);      // 1, 2, 3 ...if (c === 1) await redis.expire(`rl:${ip}`, 60);if (c > 100) return res.status(429).end();

It works, but it is two commands. If the process dies between them, the key stays forever without a TTL, and that user is blocked for good. The fix is to make it one step with a Lua script (Redis runs a script as one unbreakable step):

redis.defineCommand("hit", {  numberOfKeys: 1,  lua: `local c = redis.call("INCR", KEYS[1])        if c == 1 then redis.call("PEXPIRE", KEYS[1], ARGV[1]) end        return c`,});const count = await redis.hit(`rl:${ip}`, 60_000); // I got 1, 2, 3, 4 and a positive PTTL

Fixed windows allow bursts at the edge of two windows. Token bucket and sliding window fix that. They are covered with full code in Design Problems, Lesson 02.

Sessions

A session is the server-side record that says "this cookie belongs to user 7". Store it in a hash with a TTL: HSET session:<id> userId 7 role admin, then EXPIRE session:<id> 1800. To get a sliding timeout, call EXPIRE again on each request. Add an absolute maximum age too. The Redis server can restart, so decide: do logged-in users survive a restart? If yes, use AOF; if not, they log in again. See Backend, Lesson 06 for cookies and session safety.

Counters, leaderboards, queues

INCR gives atomic counters. A sorted set gives a leaderboard (ZADD, ZREVRANGE, ZREVRANK). Lists or streams give queues. For serious job queues in Node, people use libraries built on Redis, such as BullMQ, instead of raw lists.

Pub/sub vs streams

Pub/sub (publish/subscribe) lets one client send a message to a channel and pushes it to every client subscribed at that moment. Its delivery is at-most-once: a message arrives once, or never.

I tested this. PUBLISH with no subscribers returned 0 and the message was gone. A subscriber that was away for a moment missed the message sent in the gap. There is no history.

A stream is an append-only log stored in Redis. With a consumer group, many workers share the work, and each message must be acknowledged (XACK) when done. Messages stay in the stream after they are acknowledged (you trim it with MAXLEN), and messages that were delivered but never acknowledged can be claimed by another worker (XAUTOCLAIM). That gives at-least-once delivery.

A consumer group in code (all of this ran):

await redis.xgroup("CREATE", "orders", "workers", "0", "MKSTREAM");const res = await redis.xreadgroup("GROUP", "workers", "c1", "COUNT", 10, "BLOCK", 2000, "STREAMS", "orders", ">");// process each entry, then:await redis.xack("orders", "workers", entryId);

Distributed locks, and why Redlock has caveats

A lock makes sure only one worker does a job at a time. A distributed lock does it across many servers. In Redis the usual form is:

SET lock:invoice-7 <random-token> NX PX 30000     # NX = only if the key does not exist; PX = expire in ms

To release, you must delete the key only if it still holds your token. A plain DEL could remove another worker's lock. Check and delete together in a Lua script:

const RELEASE = `if redis.call("get",KEYS[1])==ARGV[1] then return redis.call("del",KEYS[1]) else return 0 end`;await redis.eval(RELEASE, 1, "lock:invoice-7", token);

I tested this: releasing with the wrong token returned 0, and the right token returned 1. Newer Redis versions (8.4 and later) also have a single DELEX ... IFEQ command for this, but the Lua script works everywhere.

Problems with a single-key lock:

1. The TTL can end while you are still working. A garbage-collection pause or a slow call lets the lock expire, another worker takes it, and now two workers think they own it.
2. Failover. Redis replication is asynchronous. A lock written on the primary may not have reached the replica when the primary dies. The replica becomes primary, and a second worker takes the same lock.
3. Clocks. Redis expiry uses wall-clock time, and a clock jump can end a lock early.

Redlock is an algorithm from the Redis authors for this problem. The client tries to take the lock on 5 independent Redis servers (no replication between them) and counts the lock as held only if it got a majority (3) within a short time that is less than the lock's TTL. The usable time is the TTL minus the time spent taking the lock minus a clock-drift margin.

The caveats, and what I say in interviews:

• Even the Redis docs say to use fencing tokens if correctness matters. A fencing token is a number that grows with each lock grant. The resource (for example the database) rejects any write that carries an older number than one it has already seen. This works even if a paused worker wakes up late.
• A well-known critique (by Martin Kleppmann) says timing assumptions make Redlock unsafe for correctness, and the Redis author replied. The docs link to both. My conclusion: use Redis locks for efficiency (avoid doing the same job twice), and use database constraints, transactions or fencing for correctness.

Using Redis from Node: ioredis and node-redis

Both are official clients. Both support pipelines, transactions, Lua, pub/sub and streams.

Things that surprise people (I checked each one):

• ioredis 6 uses RESP3 by default (RESP is the wire format between client and server). Version 5 used RESP2. Set protocol: 2 to keep the old behaviour. In RESP3 a subscribed connection may run normal commands such as GET; in RESP2 it throws "Connection in subscriber mode". ioredis 6 needs Node 20+.
• node-redis renamed some methods. quit() is deprecated in favour of close(), and disconnect() became destroy(). Old tutorials still use the old names.
• A cache must not make your site slower than no cache. With default ioredis options, a command to a dead server kept waiting and failed with MaxRetriesPerRequestError after about 21 seconds in my test (20 retries). For a cache, set a short commandTimeout, and consider enableOfflineQueue: false so commands fail at once (it failed in 2 ms in my test). Then catch the error and go to the database.
• A pipeline sends many commands in one network trip. It is faster, but it is not atomic. MULTI/EXEC runs commands as one block with nothing in between, but there is no rollback: a command that fails inside does not undo the others.
• Create one client per process and reuse it. Do not make one per request.
• Handle the error event on the client. An unhandled error event on a Node EventEmitter can crash the process.

const redis = new Redis(process.env.REDIS_URL, {  commandTimeout: 200,          // ms: do not let a cache call hang a request  enableOfflineQueue: false,    // fail fast while disconnected  maxRetriesPerRequest: 1,});redis.on("error", (err) => log.warn({ err }, "redis error")); // log it, do not crashasync function safeGet(key) {  try { return await redis.get(key); } catch { return null; } // treat any Redis failure as a miss}

Caching in Next.js and HTTP

Caching exists in layers, and Redis is only one of them. A request may be answered by the browser cache, a CDN, Next.js, Redis, or the database.

• In Next.js 16, "use cache" stores a function's result in server memory by default. With several servers, each has its own copy. The Next.js docs say a custom cache handler can keep the cache in Redis so all instances agree. Also, revalidateTag() is local to one instance unless the handler writes the invalidation to shared storage (updateTags()) and reads it again (refreshTags()).
• The details of "use cache", cacheLife and revalidateTag are in the Next.js lesson. The headers are in Browser, Lesson 05.
• Rule of thumb: cache as close to the user as the data allows. Public, same-for-everyone data belongs at the CDN. Private, per-user data belongs in Redis or the server, never in a shared cache without a per-user key.

Common mistakes

• No TTL on cache keys, so memory grows until eviction or an error.
• A key that leaves out something that changes the answer (user, language, tenant). Result: users see each other's data.
• Caching errors. A timeout from the database stored as "no data" for 5 minutes.
• Using KEYS in production.
• A cache write on the request path that can fail the request. Cache failures should mean "slower", not "down".
• Treating a Redis lock as a guarantee of mutual exclusion.
• Using Redis pub/sub as a job queue.
• Storing huge JSON blobs. They cost memory and network time on every read.
• Not measuring. Without hit rate and eviction numbers you are guessing.

Interview questions

Key takeaways

• A cache is a copy that may be wrong or gone. Plan how it is filled, how it is removed, and what the app does without it.
• Default to cache-aside: read the cache, then the database, then fill; on write, update the database first, then delete the key. Always have a TTL, with jitter.
• Stop stampedes with single-flight, a short lock with NX PX, early refresh, or serving stale data. Cache "not found" for a short time.
• Pick the data type for the question: hash for sessions, sorted set for ranking, set for membership, stream for reliable queues, HyperLogLog for approximate unique counts.
• RDB is a snapshot, AOF is a log (everysec by default). Use both for safety, none for a pure cache. Neither is a backup.
• The default policy is noeviction; volatile-* policies do nothing without TTLs. Use allkeys-lru or allkeys-lfu for a cache, and watch hit rate and evicted_keys.
• Pub/sub is at-most-once with no history; streams keep messages and add acknowledgements.
• A Redis lock is for efficiency. For correctness add fencing tokens or use the database. Release with a token check in Lua.
• A cache call must never take your site down: short timeouts, fail fast, treat errors as misses.

What's next

Back to the full list of full-stack lessons, or revisit the design view of caching in Design Problems, Lesson 01. When you practise, say each answer out loud with one number or one trade-off, as in the questions above.