Transactions vs Lua scripts in Redis - Visual Side-by-Side Comparison

Concept Flow - Transactions vs Lua scripts

Start Transaction

↓

Queue Commands

↓

Execute All Commands

↓

Commit or Discard

↓

Start Lua Script

↓

Run All Commands Atomically

↓

Return Result

Transactions queue commands to run all at once, while Lua scripts run all commands inside a script atomically and return results immediately.

Execution Sample

Redis

MULTI
SET key1 val1
SET key2 val2
EXEC

This Redis transaction queues two SET commands and executes them atomically.

Execution Table

Step	Action	Command	State	Output
1	Start transaction	MULTI	Transaction started, commands queued	OK
2	Queue command	SET key1 val1	Command queued	QUEUED
3	Queue command	SET key2 val2	Command queued	QUEUED
4	Execute all commands	EXEC	Commands executed atomically	["OK", "OK"]
5	End	N/A	Transaction complete	N/A

💡 All queued commands executed atomically when EXEC is called

Variable Tracker

Variable	Start	After 1	After 2	After EXEC
key1	nil	nil	nil	val1
key2	nil	nil	nil	val2
transaction_state	none	started	started	none

Key Moments - 3 Insights

Why do commands inside MULTI show QUEUED instead of immediate results?

Because commands are only queued during the transaction (see execution_table rows 2 and 3). They run only when EXEC is called (row 4).

How does a Lua script ensure atomic execution?

The entire Lua script runs as one atomic operation, so all commands inside it execute together without interruption, returning results immediately.

Can a Lua script return results while a transaction only queues commands?

Yes, Lua scripts return results after running all commands atomically, but transactions only return results after EXEC runs all queued commands.

Visual Quiz - 3 Questions

Look at the execution_table, what is the output after queuing the first SET command?

A OK

B QUEUED

C nil

D Error

💡 Hint

Check execution_table row 2, Output column

At which step do all queued commands actually run in the transaction?

A Step 2

B Step 3

C Step 4

D Step 5

💡 Hint

See execution_table row 4, Action column

If you want immediate results from multiple commands atomically, which should you use?

A Lua script

B Separate commands without transaction

C MULTI/EXEC transaction

D WATCH command

💡 Hint

Lua scripts run all commands atomically and return results immediately

Concept Snapshot

Transactions (MULTI/EXEC): queue commands, run all at once atomically, results after EXEC.
Lua scripts: run all commands inside script atomically, return results immediately.
Transactions show QUEUED until EXEC; Lua scripts execute fully in one step.
Use transactions for simple atomic batches; Lua scripts for complex logic atomically.

Full Transcript

This visual execution compares Redis transactions and Lua scripts. Transactions start with MULTI, queue commands showing QUEUED, then run all commands atomically with EXEC, returning results after. Lua scripts run all commands inside the script atomically and return results immediately. Variables like keys update only after EXEC in transactions, but update instantly in Lua scripts. Key confusions include why commands queue in transactions and how Lua scripts ensure atomicity. The quiz tests understanding of when commands run and outputs during transactions versus Lua scripts.

Practice

1. What is the main difference between Redis transactions and Lua scripts?

easy

A. Transactions run commands one by one, Lua scripts run commands outside Redis.

B. Transactions group commands to run atomically, Lua scripts run complex logic atomically inside Redis.

C. Transactions can only read data, Lua scripts can only write data.

D. Transactions are faster than Lua scripts in all cases.

Solution

1. Step 1: Understand Redis transactions

   Transactions group multiple commands to run atomically, meaning all commands succeed or none do.

2. Step 2: Understand Lua scripts in Redis

   Lua scripts run inside Redis and can include complex logic, running atomically as a single operation.

3. Final Answer:

   Transactions group commands to run atomically, Lua scripts run complex logic atomically inside Redis. -> Option B

4. Quick Check:

   Transactions vs Lua scripts = Grouped commands vs complex logic [OK]

Hint: Transactions group commands; Lua scripts add logic inside Redis [OK]

Common Mistakes:

• Thinking Lua scripts run outside Redis
• Believing transactions can only read or write
• Assuming transactions are always faster

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

easy

A. EXEC

B. START TRANSACTION

C. BEGIN

D. MULTI

Solution

1. Step 1: Recall Redis transaction commands

   Redis uses the command MULTI to start a transaction block.

2. Step 2: Identify the correct command

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

3. Final Answer:

   MULTI -> Option D

4. Quick Check:

   Start Redis transaction = MULTI [OK]

Hint: Use MULTI to start Redis transactions, EXEC to finish [OK]

Common Mistakes:

• Using SQL commands like START TRANSACTION
• Confusing EXEC as start command
• Using BEGIN which is not Redis syntax

3. Given this Lua script in Redis:

local current = redis.call('GET', KEYS[1])
if not current then
  redis.call('SET', KEYS[1], ARGV[1])
  return ARGV[1]
else
  return current
end

What will be the output if the key does not exist and ARGV[1] is "100"?

medium

A. Error

B. nil

C. "100"

D. "0"

Solution

1. Step 1: Analyze the Lua script logic

   The script checks if the key exists. If not, it sets the key to ARGV[1] and returns ARGV[1].

2. Step 2: Apply the input values

   Since the key does not exist, it sets the key to "100" and returns "100".

3. Final Answer:

   "100" -> Option C

4. Quick Check:

   Key missing sets and returns ARGV[1] = "100" [OK]

Hint: If key missing, Lua sets and returns ARGV[1] [OK]

Common Mistakes:

• Assuming nil is returned when key missing
• Expecting an error from redis.call
• Confusing return values with zero

4. You wrote this Redis transaction:

MULTI
SET key1 foo
INCR key1
EXEC

But the INCR command fails with an error. What is the likely cause?

medium

A. SET sets key1 as a string, INCR expects an integer value

B. INCR cannot be used inside MULTI blocks

C. EXEC was missing to run the transaction

D. MULTI command syntax is incorrect

Solution

1. Step 1: Understand SET and INCR behavior

   SET stores the value as a string. INCR expects the key to hold an integer value.

2. Step 2: Identify the error cause

   Since SET sets "foo" as a string, INCR fails because it cannot increment a non-integer string.

3. Final Answer:

   SET sets key1 as a string, INCR expects an integer value -> Option A

4. Quick Check:

   INCR needs integer, SET stores string [OK]

Hint: INCR needs integer; SET stores string by default [OK]

Common Mistakes:

• Thinking INCR can't be in MULTI
• Forgetting to EXEC the transaction
• Assuming MULTI syntax is wrong

5. You want to atomically check if a key exists and increment it only if it does, otherwise set it to 1. Which approach is best in Redis?

hard

A. Use a Lua script that checks and updates the key atomically

B. Use Redis pipeline to send GET and INCR commands together

C. Run separate GET and INCR commands without transactions

D. Use a Redis transaction with WATCH, GET, and MULTI commands

Solution

1. Step 1: Understand the atomicity requirement

   The operation must be atomic: check existence and update in one step without race conditions.

2. Step 2: Compare approaches

   Transactions with WATCH can be complex and may fail due to race conditions. Separate commands or pipelines are not atomic. Lua scripts run atomically inside Redis and can handle logic safely.

3. Final Answer:

   Use a Lua script that checks and updates the key atomically -> Option A

4. Quick Check:

   Atomic check and update = Lua script [OK]

Hint: Use Lua scripts for atomic logic beyond simple transactions [OK]

Common Mistakes:

• Assuming WATCH transactions are always safe
• Using separate commands risking race conditions
• Confusing pipelines with atomic execution