Transaction execution model in Redis - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ query_result

intermediate

What is the output of this Redis transaction?

Consider the following Redis commands executed as a transaction:

MULTI
SET key1 value1
INCR counter
EXEC

Assuming counter was not set before, what will be the result of the EXEC command?

Redis

MULTI
SET key1 value1
INCR counter
EXEC

A ["OK", 0]

B ["OK", "1"]

C ["OK", "0"]

D ["OK", 1]

💡 Hint

Remember that INCR initializes the key to 0 before incrementing if it does not exist.

The SET command returns OK. The INCR command increments counter from 0 to 1 and returns the new value as an integer 1. So the EXEC returns an array with ["OK", 1].

🧠 Conceptual

intermediate

Which statement best describes Redis transactions?

Which of the following statements about Redis transactions is true?

A Redis transactions guarantee atomicity and durability but not isolation.

B Redis transactions guarantee atomicity, isolation, and durability.

C Redis transactions guarantee atomicity and isolation but not durability.

D Redis transactions guarantee isolation and durability but not atomicity.

💡 Hint

Think about what Redis transactions do and do not guarantee.

Redis transactions guarantee atomicity (all commands run as one unit) and isolation (no other commands run between them). However, Redis does not guarantee durability because data may be lost if the server crashes before persistence.

📝 Syntax

advanced

Identify the syntax error in this Redis transaction block

Which option contains a syntax error that will cause the Redis transaction to fail?

MULTI
SET key1 value1
INCR
EXEC

A

MULTI
SET key1 value1
INCR
EXEC

B

MULTI
SET key1 value1
INCR counter
EXEC

C

MULTI
SET key1 value1
INCR counter
DISCARD

D

CEXE
retnuoc RCNI
1eulav 1yek TES
ITLUM

💡 Hint

Check the command arguments carefully.

The INCR command requires a key argument. Option A misses the key argument, causing a syntax error.

🔧 Debug

advanced

Why does this Redis transaction not execute any commands?

Given the commands:

WATCH key1
MULTI
SET key1 value1
EXEC

Assuming another client modifies key1 after WATCH but before EXEC, what will be the result of EXEC?

A EXEC returns null and no commands are executed.

B EXEC executes all commands and returns their results.

C EXEC returns an error because the watched key changed.

D EXEC retries the transaction automatically.

💡 Hint

Think about what happens when a watched key is modified before EXEC.

If a watched key changes before EXEC, the transaction is aborted and EXEC returns null, meaning no commands run.

❓ optimization

expert

How to optimize Redis transactions to avoid race conditions?

You want to increment a counter only if a key exists, using a Redis transaction. Which approach best avoids race conditions?

A Use WATCH on the key, then MULTI, check existence with GET, then INCR, finally EXEC.

B Use Lua scripting to check and increment atomically without WATCH or MULTI.

C Use MULTI, then GET, then INCR, then EXEC without WATCH.

D Use MULTI, then INCR, then EXEC, ignoring key existence.

💡 Hint

Think about atomic operations and avoiding race conditions.

Lua scripting runs atomically on Redis server, so checking and incrementing in one script avoids race conditions better than WATCH/MULTI.

Practice

1. What is the purpose of the MULTI command in Redis transactions?

easy

A. To discard all queued commands in a transaction

B. To immediately execute all queued commands

C. To start a transaction and queue commands for atomic execution

D. To check the status of the current transaction

Solution

1. Step 1: Understand the role of MULTI

   The MULTI command starts a transaction and queues subsequent commands instead of executing them immediately.

2. Step 2: Differentiate MULTI from other commands

   EXEC runs the queued commands, DISCARD cancels them, and no command checks status directly.

3. Final Answer:

   To start a transaction and queue commands for atomic execution -> Option C

4. Quick Check:

   MULTI = start transaction [OK]

Hint: MULTI always starts queuing commands, not executing them [OK]

Common Mistakes:

• Confusing MULTI with EXEC
• Thinking MULTI executes commands immediately
• Assuming MULTI discards commands

2. Which of the following is the correct sequence to execute a Redis transaction?

easy

A. EXEC, MULTI, commands

B. commands, MULTI, EXEC

C. commands, EXEC, MULTI

D. MULTI, commands, EXEC

Solution

1. Step 1: Recall the transaction command order

   First, MULTI starts the transaction, then commands are queued, and finally EXEC runs them.

2. Step 2: Verify the sequence

   Only MULTI, commands, EXEC follows the correct order: MULTI, then commands, then EXEC.

3. Final Answer:

   MULTI, commands, EXEC -> Option D

4. Quick Check:

   Order = MULTI -> commands -> EXEC [OK]

Hint: MULTI starts, EXEC ends transaction execution [OK]

Common Mistakes:

• Starting with EXEC instead of MULTI
• Running commands before MULTI
• Mixing order of commands and EXEC

3. Consider the following Redis transaction commands:

MULTI
SET key1 value1
INCR counter
EXEC

What will be the result of the EXEC command if counter does not exist before the transaction?

medium

A. ["OK", "(error) counter is not an integer"]

B. ["OK", 1]

C. Syntax error

D. Transaction discarded

Solution

1. Step 1: Analyze commands in the transaction

   SET key1 value1 sets a string key, and INCR counter increments the counter key. If counter does not exist, Redis treats it as 0 before incrementing.

2. Step 2: Understand Redis transaction behavior

   Redis queues commands and executes them atomically. Since counter is missing, INCR will create it with value 1. Both commands succeed.

3. Final Answer:

   ["OK", 1] -> Option B

4. Quick Check:

   INCR missing key = 1 [OK]

Hint: INCR creates missing keys with value 1 [OK]

Common Mistakes:

• Expecting error if key is missing
• Thinking transaction rolls back on error
• Confusing syntax error with runtime error

4. You run this Redis transaction:

MULTI
SET key1 value1
INCR key1
EXEC

What is the expected outcome and why?

medium

A. EXEC returns an error for INCR because key1 is not an integer

B. Both commands succeed; key1 becomes 'value1' then incremented

C. Transaction is discarded due to type error

D. Only SET executes; INCR is ignored

Solution

1. Step 1: Examine commands and data types

   SET key1 value1 sets key1 to a string. INCR key1 expects an integer but key1 is a string.

2. Step 2: Understand Redis transaction error handling

   Redis queues commands and executes all on EXEC. It does not rollback on errors. INCR fails with a type error, but SET succeeds.

3. Final Answer:

   EXEC returns an error for INCR because key1 is not an integer -> Option A

4. Quick Check:

   Type error in transaction = error on EXEC [OK]

Hint: Redis transactions don't rollback on command errors [OK]

Common Mistakes:

• Assuming transaction rolls back on error
• Expecting INCR to convert string automatically
• Thinking only first command runs

5. You want to increment a counter only if a key lock does not exist, using Redis transactions. Which sequence correctly ensures atomicity?

hard

A. WATCH lock
MULTI
INCR counter
EXEC

B. MULTI
SET lock 1
INCR counter
EXEC

C. MULTI
INCR counter
GET lock
EXEC

D. MULTI
GET lock
INCR counter
EXEC

Solution

1. Step 1: Understand the need for atomic check and increment

   You must check if lock exists and increment counter only if it does not, atomically.

2. Step 2: Use WATCH to monitor lock

   WATCH lock watches the key for changes. If lock changes before EXEC, the transaction aborts, ensuring atomicity.

3. Step 3: MULTI queues commands and EXEC runs them if lock unchanged

   This sequence ensures the increment happens only if lock was not modified.

4. Final Answer:

   WATCH lock MULTI INCR counter EXEC -> Option A

5. Quick Check:

   WATCH + MULTI = atomic check and update [OK]

Hint: Use WATCH before MULTI to ensure atomic conditional updates [OK]

Common Mistakes:

• Not using WATCH for conditional logic
• Checking key inside MULTI without WATCH
• Assuming MULTI alone ensures atomic condition