What is the difference between Redis SCAN and KEYS and why does it matter?
Learn why Redis KEYS blocks the single-threaded server and how SCAN iterates the keyspace safely with a cursor. Clear examples, pitfalls and interview tips.
Expected Interview Answer
KEYS returns all matching keys in a single blocking pass over the entire keyspace, while SCAN walks the keyspace incrementally in small cursor-based batches without blocking the server.
Redis is single-threaded, so KEYS * on a large database can stall every other client for seconds while it builds the full result set. SCAN uses a reverse-binary iteration cursor: you call it repeatedly, passing back the cursor it returns until it comes back as 0, and each call touches only a bounded slice of the keyspace. SCAN gives weaker guarantees — keys may appear more than once and keys added or removed mid-scan may or may not be seen — but it never monopolizes the event loop.
- SCAN never blocks the single-threaded server
- Bounded work per call keeps latency predictable
- Safe to run against production databases
- COUNT hint tunes batch size to your workload
- Type-specific variants (HSCAN, SSCAN, ZSCAN) iterate large collections
AI Mentor Explanation
KEYS is like demanding the scorer read out every ball of a five-day Test in one unbroken breath while the match freezes — nobody can bat until they finish. SCAN is asking for the summary over by over: you get a few deliveries, play resumes, then you ask for the next over, so the game keeps flowing while you still eventually hear every ball.
Step-by-Step Explanation
Step 1
Understand the threat
Redis executes commands on one thread, so a long KEYS call blocks all other clients until it returns.
Step 2
Start the cursor at 0
Issue SCAN 0 MATCH pattern* COUNT 100 to begin iterating; 0 means start from the beginning.
Step 3
Process the returned batch
SCAN returns a new cursor plus a slice of matching keys; act on that slice immediately.
Step 4
Loop until the cursor is 0
Feed the returned cursor back into the next SCAN call; a cursor of 0 signals the iteration is complete.
Step 5
Handle weak guarantees
Deduplicate results and tolerate keys mutated mid-scan, since SCAN may return duplicates or miss transient keys.
What Interviewer Expects
- Awareness that Redis is single-threaded
- Understanding of blocking versus incremental iteration
- Knowledge of the cursor loop protocol
- The weaker consistency guarantees of SCAN
- Mention of HSCAN/SSCAN/ZSCAN and the COUNT hint
Common Mistakes
- Claiming KEYS is fine because it is fast on small datasets
- Treating COUNT as a hard limit rather than a hint
- Forgetting to loop until the cursor returns to 0
- Assuming SCAN gives a perfect point-in-time snapshot
- Running KEYS * in production incident scripts
Best Answer (HR Friendly)
“KEYS grabs every matching key at once and freezes the whole database while it works, which is risky on a busy server. SCAN does the same job in small, safe steps that keep the server responsive, so it is the one you use in production.”
Code Example
// Avoid: KEYS blocks the single Redis thread
// await client.keys('user:*')
// Prefer: SCAN iterates in bounded batches
let cursor = '0';
do {
const [next, keys] = await client.scan(
cursor,
'MATCH', 'user:*',
'COUNT', 100
);
cursor = next;
for (const key of keys) {
await process(key);
}
} while (cursor !== '0');Follow-up Questions
- Why is Redis single-threaded and how does that affect command design?
- What guarantees does SCAN provide about duplicates and missed keys?
- How does the COUNT option influence SCAN behaviour?
- When would HSCAN, SSCAN or ZSCAN be preferable?
- How can you disable or rename the KEYS command in production?
MCQ Practice
1. Why is running KEYS * dangerous on a large production Redis instance?
Redis processes commands on one thread, so KEYS scanning the whole keyspace stalls every other client until it finishes.
2. When has a SCAN iteration finished?
SCAN is complete when it returns a cursor of 0; you must keep calling with the previous cursor until then.
3. What does the COUNT option to SCAN control?
COUNT is only a hint that tunes the amount of work per call, not a strict limit on returned keys.
Flash Cards
Why avoid KEYS in production? — It blocks the single-threaded Redis server while scanning the entire keyspace, stalling all other clients.
How does SCAN avoid blocking? — It iterates the keyspace incrementally with a cursor, doing bounded work per call so the event loop stays free.
When is a SCAN loop done? — When SCAN returns a cursor value of 0.
What weaker guarantees does SCAN accept? — Keys may be returned more than once, and keys mutated mid-scan may or may not appear.
Which variants scan inside big collections? — HSCAN for hashes, SSCAN for sets, and ZSCAN for sorted sets.
Continue Learning
Related Interview Questions
What is Redis and what makes it different from a traditional relational database?
easy
How does Redis achieve its high performance as an in-memory store?
hard
How does Redis client-side caching with CLIENT TRACKING work, and when is it worth it?
hard
What are the core data types in Redis and when do you use each?
medium