WATCH for optimistic locking in Redis - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ query_result

intermediate

What is the output of this Redis transaction with WATCH?

Consider the following Redis commands executed in sequence:

1. SET balance 100
2. WATCH balance
3. GET balance (returns 100)
4. MULTI
5. DECRBY balance 50
6. EXEC

Assuming no other client modifies balance between WATCH and EXEC, what will be the value of balance after EXEC?

Redis

SET balance 100
WATCH balance
GET balance
MULTI
DECRBY balance 50
EXEC

A 50

B 100

C EXEC returns null and balance remains 100

D Syntax error due to wrong command order

💡 Hint

WATCH monitors keys for changes; if no changes occur, EXEC applies queued commands.

Since no other client changed 'balance' after WATCH, the transaction succeeds and DECRBY reduces balance from 100 to 50.

❓ query_result

intermediate

What happens if a key changes after WATCH but before EXEC?

Given these commands:

1. SET stock 10
2. WATCH stock
3. Another client executes DECR stock
4. MULTI
5. DECR stock
6. EXEC

What will EXEC return and what is the value of stock?

Redis

SET stock 10
WATCH stock
-- another client DECR stock
MULTI
DECR stock
EXEC

A EXEC returns null and stock is 9

B EXEC returns 8 and stock is 8

C EXEC returns 9 and stock is 9

D EXEC returns error due to key change

💡 Hint

If a watched key changes, EXEC aborts and returns null.

Because another client changed 'stock' after WATCH, EXEC aborts and returns null. The stock value is 9 after the other client's DECR.

📝 Syntax

advanced

Identify the syntax error in this Redis transaction using WATCH

Which option contains a syntax error that will cause the Redis transaction to fail?

Redis

WATCH key1
MULTI
INCR key1
EXEC

A WATCH followed by MULTI and then EXEC is correct

B Calling EXEC before MULTI

C Using INCR inside MULTI without WATCH

D Using WATCH after MULTI

💡 Hint

WATCH must be called before MULTI to monitor keys.

WATCH must be called before MULTI. Calling WATCH after MULTI is invalid and causes a syntax error.

❓ optimization

advanced

How to minimize transaction aborts with WATCH in Redis?

You have a high contention key 'counter' updated by many clients using WATCH and MULTI. Which approach reduces transaction aborts best?

A Use longer transactions with multiple commands inside MULTI

B Increase the number of keys watched to detect conflicts earlier

C Use Lua scripts to perform atomic increments instead of WATCH

D Remove WATCH and rely on optimistic concurrency without monitoring

💡 Hint

Lua scripts run atomically without needing WATCH.

Lua scripts execute atomically, avoiding transaction aborts caused by WATCH conflicts.

🧠 Conceptual

expert

Why does Redis WATCH provide optimistic locking?

Select the best explanation for how WATCH implements optimistic locking in Redis.

A WATCH queues commands and executes them atomically without conflicts

B WATCH monitors keys and aborts transactions if keys change, allowing safe retries

C WATCH locks keys exclusively preventing other clients from modifying them

D WATCH duplicates keys to a temporary store for isolated transactions

💡 Hint

Optimistic locking means detecting conflicts rather than preventing them.

WATCH detects if keys change after being watched and aborts the transaction to avoid conflicts, enabling optimistic concurrency control.