Multi-key transactions for consistency 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:

WATCH balance:alice balance:bob
MULTI
DECRBY balance:alice 50
INCRBY balance:bob 50
EXEC

Assuming initial balances are balance:alice = 100 and balance:bob = 200, what will be the balances after EXEC if no other client modifies these keys?

Redis

WATCH balance:alice balance:bob
MULTI
DECRBY balance:alice 50
INCRBY balance:bob 50
EXEC

A balance:alice = 100, balance:bob = 200

B balance:alice = 50, balance:bob = 200

C balance:alice = 50, balance:bob = 250

D balance:alice = 100, balance:bob = 250

💡 Hint

Think about what MULTI and EXEC do together with WATCH.

The WATCH command monitors keys for changes. Since no other client modifies the keys, EXEC runs the queued commands atomically, decreasing Alice's balance by 50 and increasing Bob's by 50.

🧠 Conceptual

intermediate

Why use WATCH in Redis transactions?

What is the main purpose of the WATCH command in Redis transactions?

A To monitor keys for changes and abort the transaction if they change

B To automatically retry the transaction if it fails

C To queue commands for atomic execution

D To lock keys so no other client can read them during the transaction

💡 Hint

Think about how Redis detects conflicts in transactions.

WATCH monitors keys and if any change before EXEC, the transaction aborts to avoid inconsistent updates.

📝 Syntax

advanced

Identify the syntax error in this Redis transaction script

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

Redis

WATCH key1 key2
MULTI
INCR key1
DECR key2
EXEC

A

WATCH key1 key2
MULTI
INCR key1
DECR key2
EXEC
DISCARD

B

WATCH key1 key2
MULTI
INCR key1
DECR key2
EXEC extra_arg

C

WATCH key1 key2
MULTI
INCR key1
DECR key2
EXEC

D

CEXE
2yek RCED
1yek RCNI
ITLUM
2yek 1yek HCTAW

💡 Hint

Check the EXEC command syntax carefully.

EXEC does not accept any arguments. Adding extra arguments causes a syntax error.

❓ optimization

advanced

How to optimize multi-key updates for consistency in Redis?

You want to atomically update multiple keys in Redis and ensure no other client modifies them during your update. Which approach is best?

A Update keys one by one without transactions

B Use MULTI/EXEC without WATCH and hope no conflicts occur

C Use Lua scripting to perform all updates atomically without WATCH

D Use WATCH on all keys, then MULTI/EXEC to queue updates, retry if EXEC returns null

💡 Hint

Consider how Redis handles optimistic locking and atomicity.

WATCH monitors keys for changes, MULTI/EXEC queues commands atomically, and retrying on EXEC null ensures consistency.

🔧 Debug

expert

Why does this Redis transaction fail to update balances consistently?

Given this Redis transaction:

WATCH balance:alice balance:bob
MULTI
DECRBY balance:alice 50
INCRBY balance:bob 50
EXEC

Sometimes, the balances are not updated as expected. What is the most likely cause?

A Another client modified balance:alice or balance:bob after WATCH but before EXEC, causing EXEC to return null

B WATCH locks the keys preventing any updates, so EXEC fails

C The DECRBY and INCRBY commands are not atomic inside MULTI/EXEC

D Redis does not support multi-key transactions

💡 Hint

Think about what happens if keys change after WATCH.

If keys change after WATCH, EXEC returns null and the transaction does not apply updates, causing inconsistent balances.

Practice

1. What is the main purpose of using MULTI and EXEC commands in Redis transactions?

easy

A. To group multiple commands so they execute atomically for data consistency

B. To speed up the execution of individual Redis commands

C. To create backups of the Redis database automatically

D. To delete multiple keys at once

Solution

1. Step 1: Understand MULTI command

   The MULTI command starts a transaction block in Redis, grouping commands.

2. Step 2: Understand EXEC command

   The EXEC command executes all commands queued after MULTI atomically, ensuring consistency.

3. Final Answer:

   To group multiple commands so they execute atomically for data consistency -> Option A

4. Quick Check:

   Atomic execution = Data consistency [OK]

Hint: MULTI starts, EXEC runs all commands atomically [OK]

Common Mistakes:

• Thinking MULTI speeds up commands individually
• Confusing transactions with backups
• Assuming EXEC deletes keys

2. Which of the following is the correct syntax to start a Redis transaction?

easy

A. EXEC

B. START

C. BEGIN

D. MULTI

Solution

1. Step 1: Identify Redis transaction start command

   Redis uses MULTI to begin a transaction block.

2. Step 2: Check other options

   EXEC ends the transaction, BEGIN and START are not Redis commands.

3. Final Answer:

   MULTI -> Option D

4. Quick Check:

   Start transaction = MULTI [OK]

Hint: Start with MULTI, end with EXEC [OK]

Common Mistakes:

• Using EXEC to start instead of end
• Using SQL-like BEGIN or START commands
• Confusing transaction commands with key commands

3. Consider the following Redis commands executed in a transaction:

MULTI
SET key1 "value1"
SET key2 "value2"
EXEC

What will be the state of key1 and key2 after EXEC?

medium

A. key1 and key2 will both have their new values set atomically

B. Only key1 will be set, key2 will remain unchanged

C. Neither key1 nor key2 will be set because EXEC fails

D. key1 will be set, but key2 will be deleted

Solution

1. Step 1: Understand MULTI and EXEC behavior

   Commands between MULTI and EXEC are queued and executed atomically.

2. Step 2: Analyze the commands

   Both SET key1 "value1" and SET key2 "value2" will be applied together when EXEC runs.

3. Final Answer:

   key1 and key2 will both have their new values set atomically -> Option A

4. Quick Check:

   Atomic set of keys = Both keys updated [OK]

Hint: EXEC applies all queued commands together [OK]

Common Mistakes:

• Thinking commands run immediately after MULTI
• Assuming partial execution on EXEC failure
• Confusing EXEC with DISCARD

4. You wrote this Redis transaction:

MULTI
SET key1 "val1"
GET key1
EXEC

But the GET key1 command returns null inside the transaction. Why?

medium

A. SET command failed, so GET returns null

B. GET command syntax is incorrect

C. GET inside MULTI queues the command and returns null until EXEC runs

D. EXEC was not called, so commands did not run

Solution

1. Step 1: Understand command queuing in MULTI

   Inside a transaction, commands are queued and do not execute immediately.

2. Step 2: Effect on GET command

   GET returns null because the SET has not executed yet; actual results come after EXEC.

3. Final Answer:

   GET inside MULTI queues the command and returns null until EXEC runs -> Option C

4. Quick Check:

   Queued commands return null before EXEC [OK]

Hint: GET returns null inside MULTI before EXEC [OK]

Common Mistakes:

• Thinking GET runs immediately inside MULTI
• Assuming SET failed without checking
• Forgetting to call EXEC

5. You want to update two related keys account:balance and account:points atomically in Redis. Which approach ensures both keys update together or not at all?

hard

A. Use GET to check keys, then SET commands separately

B. Use MULTI, queue both SET commands, then EXEC to apply atomically

C. Use WATCH on both keys, then run SET commands without MULTI

D. Run two separate SET commands without MULTI

Solution

1. Step 1: Understand atomic updates need transactions

   To update multiple keys together, Redis transactions with MULTI and EXEC ensure atomicity.

2. Step 2: Analyze other options

   Separate SET commands risk partial updates; WATCH helps optimistic locking but needs MULTI for atomicity.

3. Final Answer:

   Use MULTI, queue both SET commands, then EXEC to apply atomically -> Option B

4. Quick Check:

   Atomic multi-key update = MULTI + EXEC [OK]

Hint: MULTI + EXEC ensures all-or-nothing updates [OK]

Common Mistakes:

• Running SET commands separately risking partial updates
• Using WATCH without MULTI for atomicity
• Relying on GET before SET without transaction