Multi-key transactions for consistency in Redis - Step-by-Step Execution

Concept Flow - Multi-key transactions for consistency

Start Transaction

↓

Queue Commands on Keys

↓

Execute All Commands Atomically

↓

Check for Success or Failure

↓

Commit if Success

No→Discard Transaction

↓

End Transaction

This flow shows how Redis queues multiple commands on different keys and executes them all at once to keep data consistent.

Execution Sample

Redis

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

This Redis transaction sets two keys atomically to keep data consistent.

Execution Table

Step	Command	Action	State Change	Result
1	MULTI	Start transaction mode	Commands queued, no changes yet	OK
2	SET key1 "value1"	Queue SET for key1	key1 not changed yet	QUEUED
3	SET key2 "value2"	Queue SET for key2	key2 not changed yet	QUEUED
4	EXEC	Execute all queued commands atomically	key1 = "value1", key2 = "value2"	["OK", "OK"]
5	End	Transaction ends	All changes committed	Transaction complete

💡 EXEC runs all queued commands atomically, ensuring both keys update together or not at all.

Variable Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	Final
key1	null	null	null	"value1"	"value1"
key2	null	null	null	"value2"	"value2"
Transaction State	Not started	Started	Started	Committed	Committed

Key Moments - 2 Insights

Why don't the keys change immediately after SET commands inside MULTI?

Because inside MULTI, commands are only queued (see steps 2 and 3 in execution_table). Actual changes happen only after EXEC runs all commands atomically (step 4).

What happens if EXEC fails or is not called?

If EXEC is not called or fails, none of the queued commands run, so keys remain unchanged, ensuring consistency (exit_note explains atomic execution).

Visual Quiz - 3 Questions

Look at the execution_table, what is the state of key1 after step 3?

A QUEUED

B "value1"

C null

D Error

💡 Hint

Check the 'State Change' column at step 3 where commands are queued but keys not changed yet.

At which step do both keys get their new values?

A Step 4

B Step 2

C Step 3

D Step 5

💡 Hint

Look at the 'Action' and 'State Change' columns in step 4 where EXEC runs all commands atomically.

If EXEC was never called, what would be the final state of the keys?

A Both keys updated

B No keys updated

C Only key1 updated

D Only key2 updated

💡 Hint

Refer to key_moments about what happens if EXEC is not called.

Concept Snapshot

Redis MULTI starts a transaction.
Commands like SET are queued, not executed immediately.
EXEC runs all queued commands atomically.
This ensures multi-key updates happen together or not at all.
If EXEC is not called, no changes happen.
Use this to keep data consistent across keys.

Full Transcript

This visual execution shows how Redis multi-key transactions work. First, MULTI starts the transaction mode where commands are queued but not executed. Then SET commands for different keys are queued. Only when EXEC is called, all queued commands run together atomically, updating all keys at once. This prevents partial updates and keeps data consistent. If EXEC is not called, no changes happen. The variable tracker shows keys remain unchanged until EXEC runs. This method is useful to update multiple keys safely in Redis.