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.