WATCH for optimistic locking in Redis - Step-by-Step Execution

Concept Flow - WATCH for optimistic locking

Start Transaction

↓

WATCH key(s)

↓

Read current value(s)

↓

MULTI - start commands queue

↓

Queue commands

↓

EXEC - try to commit

↓

Success

↓

Retry or Abort

WATCH monitors keys for changes before transaction; if keys change, EXEC aborts to prevent conflicts.

Execution Sample

Redis

WATCH balance
val = GET balance
MULTI
SET balance val-10
EXEC

This sequence watches 'balance', reads it, queues a decrement, then tries to commit if no changes.

Execution Table

Step	Command	Action	Key State Before	Key State After	Result
1	WATCH balance	Start watching 'balance'	balance=100	balance=100	OK
2	GET balance	Read current value	balance=100	balance=100	100
3	MULTI	Start transaction queue	balance=100	balance=100	OK
4	SET balance 90	Queue command to set balance to 90	balance=100	balance=100	QUEUED
5	EXEC	Try to commit transaction	balance=100	balance=90	[OK]
6	End	Transaction complete	balance=90	balance=90	Success

💡 EXEC commits because 'balance' was not changed after WATCH; transaction succeeds.

Variable Tracker

Variable	Start	After Step 2	After Step 5	Final
balance	100	100	90	90
transaction_state	none	none	committed	committed

Key Moments - 2 Insights

Why does EXEC fail if the watched key changes before EXEC?

Because WATCH detects the key change and causes EXEC to return NULL, aborting the transaction to avoid conflicts (see execution_table step 5).

What happens if you don't call MULTI after WATCH?

Commands run immediately without transaction; WATCH has no effect without MULTI/EXEC (no queuing or atomic commit).

Visual Quiz - 3 Questions

Look at the execution table, what is the value of 'balance' after step 2?

A 90

B 100

C NULL

D 110

💡 Hint

Check 'Key State Before' and 'Result' columns at step 2 in execution_table.

At which step does the transaction actually commit the changes?

A Step 3 (MULTI)

B Step 4 (SET command queued)

C Step 5 (EXEC)

D Step 1 (WATCH)

💡 Hint

Look for when 'transaction_state' changes to 'committed' in variable_tracker and 'Result' in execution_table.

If another client changes 'balance' after WATCH but before EXEC, what will EXEC return?

A NULL - transaction aborted

B OK - transaction committed

C Error - syntax error

D QUEUED - commands queued

💡 Hint

Recall the behavior described in key_moments about EXEC aborting if watched keys change.

Concept Snapshot

WATCH key(s) monitors keys for changes.
MULTI starts a transaction queue.
Commands are queued until EXEC.
EXEC commits if keys unchanged; else aborts.
Use WATCH to avoid race conditions in Redis.

Full Transcript

In Redis, WATCH is used for optimistic locking by monitoring keys for changes before a transaction. First, WATCH is called on keys to monitor. Then the current values are read. MULTI starts queuing commands. Commands like SET are queued but not executed yet. EXEC tries to commit all queued commands atomically. If any watched key changed after WATCH, EXEC aborts and returns NULL to avoid conflicts. Otherwise, EXEC commits changes. This prevents race conditions when multiple clients modify the same keys concurrently.