SCAN for safe key iteration in Redis - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ query_result

intermediate

What does the following Redis SCAN command return?

Consider a Redis database with keys: user:1, user:2, session:1, session:2. What will be the output of this command?

SCAN 0 MATCH user:*

Assume the database is static during the scan.

Redis

SCAN 0 MATCH user:*

A A cursor and a list containing keys starting with 'user:' such as ['user:1', 'user:2']

B All keys in the database regardless of pattern

C An error because SCAN does not accept MATCH

D Only the key 'user:*' if it exists

💡 Hint

Remember SCAN returns a cursor and a list of keys matching the pattern.

The SCAN command returns a cursor and a list of keys matching the pattern. Here, it returns keys starting with 'user:'.

🧠 Conceptual

intermediate

Why is SCAN preferred over KEYS for iterating keys in Redis?

Which reason best explains why SCAN is safer to use than KEYS in a production Redis environment?

A SCAN deletes keys as it scans, freeing memory

B SCAN returns all keys at once, making it faster than KEYS

C SCAN uses a cursor and returns keys incrementally, avoiding blocking the server

D SCAN only works on sorted sets, making it more efficient

💡 Hint

Think about server load and blocking behavior.

SCAN returns keys incrementally using a cursor, so it does not block the server like KEYS, which returns all keys at once.

📝 Syntax

advanced

Which SCAN command syntax correctly scans keys with a pattern and count?

Select the correct Redis SCAN command to scan keys matching 'cache:*' and return approximately 50 keys per iteration.

A SCAN 0 MATCH cache:* COUNT 50

B SCAN MATCH cache:* COUNT 50 0

C SCAN 0 COUNT 50 MATCH cache:*

D SCAN 0 MATCH cache:* LIMIT 50

💡 Hint

The order of MATCH and COUNT matters.

The correct syntax is SCAN MATCH COUNT . Option A follows this order.

❓ optimization

advanced

How to optimize SCAN usage to reduce server load?

You want to scan all keys matching 'temp:*' without causing high CPU usage. Which approach is best?

A Use SCAN without MATCH to get all keys faster

B Use KEYS command instead for faster results

C Use SCAN with a very large COUNT value to get all keys quickly

D Use SCAN with a small COUNT value and pause between calls

💡 Hint

Think about balancing speed and server load.

Using a small COUNT and pausing between calls reduces CPU spikes and server load.

🔧 Debug

expert

Why does this SCAN loop miss some keys?

A developer uses this loop to scan all keys matching 'data:*':

cursor = 0 keys = [] do { result = redis.scan(cursor, match='data:*') cursor = result[0] keys.extend(result[1]) } while cursor != 0

Some keys are missing after the loop finishes. What is the most likely cause?

Redis

cursor = 0
keys = []
do {
  result = redis.scan(cursor, match='data:*')
  cursor = result[0]
  keys.extend(result[1])
} while cursor != 0

A The MATCH pattern is incorrect and filters out keys

B Keys were added or deleted during the scan causing inconsistent results

C The loop should stop when cursor equals 1, not 0

D SCAN does not return all keys by design, so missing keys are normal

💡 Hint

Think about what happens if keys change during iteration.

If keys are added or deleted during SCAN, some keys may be missed or returned multiple times because SCAN is not atomic.

Practice

1. What is the main advantage of using SCAN over KEYS in Redis for iterating keys?

easy

A. SCAN returns all keys at once for faster access.

B. SCAN only works with sorted sets.

C. SCAN deletes keys while iterating.

D. SCAN does not block Redis and returns keys in batches.

Solution

1. Step 1: Understand KEYS behavior

   KEYS returns all matching keys at once and blocks Redis during execution.

2. Step 2: Understand SCAN behavior

   SCAN returns keys in small batches without blocking Redis, allowing safe iteration.

3. Final Answer:

   SCAN does not block Redis and returns keys in batches. -> Option D

4. Quick Check:

   Safe iteration = SCAN non-blocking [OK]

Hint: Remember: SCAN is non-blocking, KEYS blocks [OK]

Common Mistakes:

• Thinking SCAN returns all keys at once
• Confusing SCAN with key deletion
• Assuming SCAN only works on sorted sets

2. Which of the following is the correct syntax to start a SCAN iteration from the beginning in Redis CLI?

easy

A. SCAN 1

B. SCAN 0

C. SCAN *

D. SCAN start

Solution

1. Step 1: Identify the starting cursor for SCAN

   The SCAN command requires a cursor argument; starting cursor is always 0.

2. Step 2: Check options for correct cursor

   SCAN 0 starts iteration from the beginning; other options are invalid.

3. Final Answer:

   SCAN 0 -> Option B

4. Quick Check:

   Start cursor = 0 [OK]

Hint: Always start SCAN with cursor 0 [OK]

Common Mistakes:

• Starting with cursor 1 instead of 0
• Using wildcard * as cursor
• Using invalid strings like 'start'

3. Given the following Redis commands executed sequentially, what will be the output of the last SCAN command?

SET user:1 Alice
SET user:2 Bob
SET admin:1 Carol
SCAN 0 MATCH user:*

medium

A. [cursor, ["user:1", "user:2"]]

B. [0, ["user:1", "user:2"]]

C. [cursor, ["user:1", "user:2", "admin:1"]]

D. [0, ["admin:1"]]

Solution

1. Step 1: Understand SCAN with MATCH

   The MATCH user:* filters keys starting with 'user:'. So keys 'user:1' and 'user:2' match; 'admin:1' does not.

2. Step 2: Understand SCAN output format

   SCAN returns a two-element array: a cursor (string) and a list of keys matching the pattern in this batch. Cursor is not necessarily 0 unless iteration is complete.

3. Final Answer:

   [cursor, ["user:1", "user:2"]] -> Option A

4. Quick Check:

   Filtered keys = user keys only [OK]

Hint: MATCH filters keys; cursor is a string, not always 0 [OK]

Common Mistakes:

• Expecting cursor 0 on first SCAN call
• Including keys not matching pattern
• Confusing cursor with count

4. You wrote this Redis command to iterate keys safely:

SCAN 0 MATCH user:*

But you notice it returns only a partial list of keys matching the pattern. What is the likely mistake?

medium

A. Not repeating SCAN with the returned cursor until it returns 0.

B. Using MATCH with an incorrect pattern.

C. Starting SCAN with cursor 1 instead of 0.

D. Using COUNT option with a value too high.

Solution

1. Step 1: Understand SCAN iteration process

   SCAN returns a cursor and a batch of keys; to get all keys, you must repeat SCAN with the new cursor until it returns 0.

2. Step 2: Identify the mistake

   Running SCAN 0 MATCH user:* only once returns partial keys; not looping causes incomplete results.

3. Final Answer:

   Not repeating SCAN with the returned cursor until it returns 0. -> Option A

4. Quick Check:

   Repeat SCAN until cursor 0 [OK]

Hint: Always loop SCAN calls until cursor returns 0 [OK]

Common Mistakes:

• Expecting all keys in one SCAN call
• Misusing MATCH pattern syntax
• Starting with wrong cursor

5. You want to safely iterate all keys starting with session: in Redis but avoid blocking the server. You also want to limit each batch to about 10 keys. Which command sequence correctly achieves this?

hard

A. Use SCAN 0 COUNT 10 without MATCH.

B. Run KEYS session:* once to get all keys.

C. Repeat SCAN cursor MATCH session:* COUNT 10 until cursor returns 0.

D. Use SCAN 0 MATCH session:* once without COUNT.

Solution

1. Step 1: Use SCAN with MATCH and COUNT

   To filter keys starting with 'session:' and limit batch size, use MATCH session:* and COUNT 10.

2. Step 2: Repeat SCAN calls until cursor is 0

   Iterate by passing the returned cursor each time until it returns 0 to get all keys safely without blocking.

3. Final Answer:

   Repeat SCAN cursor MATCH session:* COUNT 10 until cursor returns 0. -> Option C

4. Quick Check:

   Safe iteration + filter + batch size = Repeat SCAN cursor MATCH session:* COUNT 10 until cursor returns 0. [OK]

Hint: Combine MATCH and COUNT, loop until cursor 0 [OK]

Common Mistakes:

• Using KEYS which blocks Redis
• Not looping SCAN calls
• Omitting MATCH or COUNT when needed