Why transactions ensure atomicity in Redis - Visual Breakdown

Concept Flow - Why transactions ensure atomicity

Start Transaction (MULTI)

↓

Queue Commands

↓

EXEC

↓

End Transaction

This flow shows how Redis transactions group commands to execute atomically during EXEC, preventing interleaving. Note: no rollback on individual command errors.

Execution Sample

Redis

MULTI
SET key1 100
INCR key1
EXEC

This Redis transaction sets key1 to 100, then increments it, executing both commands atomically.

Execution Table

Step	Command	Action	State Change	Result
1	MULTI	Start transaction mode	Commands queued, no immediate change	OK
2	SET key1 100	Queue SET command	No change yet	QUEUED
3	INCR key1	Queue INCR command	No change yet	QUEUED
4	EXEC	Execute all queued commands atomically	key1 set to 100, then incremented to 101	["OK", 101]

💡 Transaction ends after EXEC, all commands applied together ensuring atomicity

Variable Tracker

Variable	Start	After MULTI	After SET queued	After INCR queued	After EXEC	Final
key1	null	null	null	null	101	101

Key Moments - 2 Insights

Why doesn't the SET command change key1 immediately after MULTI?

Because commands are only queued during MULTI mode and not executed until EXEC, as shown in execution_table rows 2 and 3.

What happens if one command fails during EXEC?

Redis does not discard all commands. All queued commands execute sequentially during EXEC; failing commands return errors, but prior changes are committed (no rollback).

Visual Quiz - 3 Questions

Look at the execution_table, what is the state of key1 after the INCR command is queued but before EXEC?

A key1 is null (unchanged)

B key1 is 101

C key1 is 100

D key1 is set to an error

💡 Hint

Check execution_table rows 3 and 4; commands are queued but not executed until EXEC

At which step are all commands executed atomically?

A MULTI

B SET key1 100

C EXEC

D INCR key1

💡 Hint

Refer to execution_table row 4 where EXEC runs all queued commands

If the INCR command failed during EXEC, what would happen to key1?

A key1 would remain unchanged

B key1 would be set to 100 only

C key1 would be incremented anyway

D key1 would be set to an error value

💡 Hint

Refer to key_moments[1]; Redis has no rollback on command failure during EXEC

Concept Snapshot

Redis transactions use MULTI and EXEC to queue commands.
Commands run all at once atomically during EXEC.
This ensures atomicity: no interleaving, sequential execution.
Command failures return errors (no rollback).
Use MULTI to start, EXEC to commit.

Full Transcript

In Redis, transactions ensure atomicity by grouping commands between MULTI and EXEC. When MULTI is issued, commands are queued but not executed immediately. Only when EXEC runs, all queued commands execute together atomically (no interleaving). Command failures return errors with no rollback—prior changes apply. This keeps data execution bundled and consistent.

Practice

1. What does atomicity mean in the context of Redis transactions?

easy

A. All commands in a transaction run completely or not at all

B. Commands run one by one without grouping

C. Commands run only if the server is idle

D. Commands run in parallel to speed up processing

Solution

1. Step 1: Understand atomicity in transactions

   Atomicity means a group of commands execute as a single unit without interruption.

2. Step 2: Apply to Redis transactions

   Redis transactions ensure all commands inside MULTI/EXEC run fully or none run at all.

3. Final Answer:

   All commands in a transaction run completely or not at all -> Option A

4. Quick Check:

   Atomicity = All or nothing [OK]

Hint: Atomicity means all commands succeed or none do [OK]

Common Mistakes:

• Thinking commands run separately
• Believing commands run only if server is idle
• Confusing atomicity with parallel execution

2. Which Redis command starts a transaction to ensure atomicity?

easy

A. WATCH

B. EXEC

C. MULTI

D. DISCARD

Solution

1. Step 1: Identify the command that begins a transaction

   MULTI is the Redis command that marks the start of a transaction block.

2. Step 2: Differentiate from other commands

   EXEC runs the queued commands, WATCH monitors keys, DISCARD cancels the transaction.

3. Final Answer:

   MULTI -> Option C

4. Quick Check:

   Start transaction = MULTI [OK]

Hint: MULTI starts the transaction block in Redis [OK]

Common Mistakes:

• Confusing EXEC as the start command
• Using WATCH to start transactions
• Mistaking DISCARD for starting transactions

3. Consider this Redis transaction:

MULTI
SET key1 value1
SET key2 value2
EXEC

What will happen if the server crashes after SET key1 value1 but before EXEC?

medium

A. Only key1 is set, key2 is not

B. Neither key1 nor key2 is set

C. Both key1 and key2 are set

D. Partial data may be set randomly

Solution

1. Step 1: Understand Redis transaction queuing

   Commands inside MULTI are queued but not executed until EXEC runs.

2. Step 2: Analyze crash timing

   If the server crashes before EXEC, none of the queued commands run, so no keys are set.

3. Final Answer:

   Neither key1 nor key2 is set -> Option B

4. Quick Check:

   Commands run only after EXEC [OK]

Hint: Commands run only after EXEC, not when queued [OK]

Common Mistakes:

• Assuming queued commands run immediately
• Thinking partial commands execute before EXEC
• Believing crash allows partial data writes

4. You wrote this Redis transaction:

MULTI
SET key1 value1
SET key2 value2
DISCARD
EXEC

What is the problem with this code?

medium

A. DISCARD cancels the transaction, so EXEC has nothing to run

B. EXEC will run commands even after DISCARD

C. MULTI cannot be used with DISCARD

D. SET commands are invalid inside transactions

Solution

1. Step 1: Understand DISCARD effect

   DISCARD cancels all queued commands in the current transaction.

2. Step 2: Analyze EXEC after DISCARD

   After DISCARD, EXEC has no commands to execute, so it does nothing.

3. Final Answer:

   DISCARD cancels the transaction, so EXEC has nothing to run -> Option A

4. Quick Check:

   DISCARD clears queue before EXEC [OK]

Hint: DISCARD cancels queued commands before EXEC runs [OK]

Common Mistakes:

• Thinking EXEC runs commands after DISCARD
• Believing MULTI and DISCARD cannot be combined
• Assuming SET commands are invalid in transactions

5. You want to ensure two keys update atomically only if neither key changes during the transaction. Which Redis commands should you use together?

hard

A. MULTI and EXEC only

B. DISCARD and EXEC

C. SETNX and GET

D. WATCH, MULTI, and EXEC

Solution

1. Step 1: Understand WATCH role

   WATCH monitors keys for changes and aborts the transaction if keys change before EXEC.

2. Step 2: Combine WATCH with MULTI/EXEC

   Use WATCH to monitor keys, then MULTI to start transaction, and EXEC to run atomically if keys unchanged.

3. Final Answer:

   WATCH, MULTI, and EXEC -> Option D

4. Quick Check:

   WATCH + MULTI/EXEC ensures atomic conditional update [OK]

Hint: Use WATCH before MULTI to ensure keys unchanged [OK]

Common Mistakes:

• Using MULTI/EXEC without WATCH for conditional updates
• Confusing DISCARD with conditional execution
• Using SETNX and GET without transaction control