Lua vs transactions comparison in Redis - Practice Questions

Challenge - 5 Problems

🧠 Conceptual

intermediate

Atomicity in Redis: Lua Scripts vs Transactions

Which statement best describes the atomicity guarantee when using Lua scripts compared to Redis transactions?

A Lua scripts and transactions both guarantee atomicity only if the MULTI command is used inside the script.

B Transactions in Redis are fully atomic, but Lua scripts can be interrupted by other commands causing partial execution.

C Both Lua scripts and transactions execute commands one by one without atomic guarantees.

D Lua scripts execute atomically, ensuring all commands run as a single unit without interruption, while transactions may allow other commands to interleave between MULTI and EXEC.

💡 Hint

Think about how Redis handles command execution inside Lua scripts versus MULTI/EXEC blocks.

Lua scripts in Redis run atomically, meaning all commands inside the script execute as a single, uninterrupted operation. Transactions using MULTI/EXEC queue commands and execute them atomically, but other commands may interleave between MULTI and EXEC.

❓ query_result

intermediate

Result of Concurrent Writes: Lua Script vs Transaction

Given two clients concurrently incrementing the same Redis key, which approach prevents race conditions?

Client 1 uses a Lua script to increment the key. Client 2 uses MULTI/EXEC transaction commands to increment the key.

What is the expected behavior?

A Neither Lua scripts nor transactions prevent race conditions; external locking is required.

B The Lua script ensures increments are atomic and race conditions are prevented; the transaction may allow race conditions if commands overlap.

C Both Lua scripts and transactions prevent race conditions equally by locking the key during execution.

D Transactions prevent race conditions by queuing commands, but Lua scripts do not provide any concurrency control.

💡 Hint

Consider how Redis executes Lua scripts and transactions in the context of concurrent clients.

Lua scripts execute atomically, so concurrent increments via scripts do not cause race conditions. Transactions queue commands and execute them atomically, but overlapping transactions can cause race conditions if commands are not properly isolated.

📝 Syntax

advanced

Identify the Correct Lua Script Syntax for Atomic Increment

Which Lua script correctly increments a Redis key atomically?

Redis

local current = redis.call('GET', KEYS[1])
local new = tonumber(current) + 1
redis.call('SET', KEYS[1], new)
return new

A

local current = redis.call('GET', KEYS[1])
local new = tonumber(current) + 1
redis.call('SET', KEYS[1], tostring(new))
return new

B

local current = redis.call('GET', KEYS[1])
local new = current + 1
redis.call('SET', KEYS[1], new)
return new

C

local current = redis.call('GET', KEYS[1])
local new = tonumber(current) + 1
redis.call('SET', KEYS[1], new)
return new

D

local current = redis.call('GET', KEYS[1])
local new = tonumber(current) + 1
redis.call('SET', KEYS[1], new)
return tostring(new)

💡 Hint

Remember Redis stores strings, so the value set must be a string.

Redis expects string values for SET commands. Option A converts the incremented number back to a string before setting it, ensuring correct data type and no errors.

❓ optimization

advanced

Optimizing Multiple Commands: Lua Script vs Transaction

You want to execute multiple Redis commands atomically and efficiently. Which approach is generally faster and why?

A Using a transaction with MULTI/EXEC is faster because it pipelines commands and executes them in batch.

B Both approaches have the same performance because Redis processes commands sequentially regardless of method.

C Using a Lua script is faster because it runs all commands server-side in one call, reducing network overhead and ensuring atomicity.

D Using multiple separate commands without transactions or scripts is faster due to parallel execution.

💡 Hint

Think about network round-trips and server-side execution.

Lua scripts execute all commands inside Redis in one call, reducing network round-trips and ensuring atomic execution. Transactions still require multiple commands sent from client to server.

🔧 Debug

expert

Debugging a Redis Transaction Failure

A Redis transaction using MULTI/EXEC fails silently and does not apply any commands. Which of the following is the most likely cause?

A One of the commands inside the transaction is invalid or causes an error, causing EXEC to abort all commands.

B The transaction was not started with the MULTI command, so EXEC has no commands to execute.

C The client did not wait for the EXEC reply, so the commands were executed but the client missed the response.

D Redis transactions do not support atomic execution, so commands are applied partially and silently fail.

💡 Hint

Consider how Redis handles errors inside transactions.

If any command queued in a MULTI block is invalid, EXEC will abort and not apply any commands, causing silent failure of the transaction.