Lesson 13. MULTI/EXEC and Optimistic Locking with WATCH

Mission link: Stage 8 opens the mechanism that actually makes a check-then-act sequence safe against another client acting in between, the same problem lesson 4's naive lock existed to solve at a coarser grain. This lesson is Redis's own transaction primitive, and where it falls short of a real lock.
Primary source: Docs: "Data types", Redis
Prerequisites: Lesson 12, Eviction policy

Warm-up

1. ▢ Why does active expiration exist, given that lazy expiration alone already guarantees a client never sees an expired value?

2. ▢ Why doesn't a Redis replica expire a key on its own local clock?

Know this

MULTI/EXEC: queue several commands, run them without anything interleaving

MULTI starts queuing every subsequent command on that connection instead of running it immediately; EXEC runs the entire queued batch as one uninterruptible block, no other client's command can execute in between any two of them. DISCARD abandons a queued transaction before EXEC runs it at all. This gives a script "do these several things together, with nothing else able to interleave," the same property a database transaction's isolation guarantees, applied here to a sequence of Redis commands rather than SQL statements.

What MULTI/EXEC doesn't give you: no rollback on a runtime error

A command queued inside MULTI that fails at actual execution time (incrementing a key that holds a string, say) doesn't roll back the whole transaction the way a SQL transaction would; the other queued commands still run, and the failing one simply reports its own error inline in the results EXEC returns. Only an error caught before EXEC even runs (queuing a genuinely unknown command) aborts the batch entirely. This is a real, narrower guarantee than "transaction" tends to imply in a relational-database context: atomic as in "nothing interleaves," not atomic as in "all or nothing on a failure."

WATCH: detecting that a value changed before you act on it

WATCH key marks a key for optimistic monitoring before a MULTI block begins; if any client modifies that key between the WATCH and the eventual EXEC, Redis aborts the transaction entirely, EXEC returns nil, and nothing in the queued block runs at all. This is optimistic concurrency control: rather than blocking other clients from touching the key (the way lesson 4's lock tries to, at a real correctness cost lesson 5 exposed), a WATCH-based sequence proceeds hopefully and detects, after the fact, whether it was actually safe to have proceeded, retrying the whole read-modify-write sequence from scratch if not.

Why this is a distinct tool from a lock, not a replacement for one

A WATCH/MULTI/EXEC sequence solves "did the value I based my write on change before I could commit it," a compare-and-swap pattern, useful for a counter or a balance update that has to account for a concurrent change rather than blindly overwrite it. It does not solve lesson 4 and 5's problem, coordinating exclusive access across a longer critical section that isn't just "read one value, compute, write it back." A client holding a lock is claiming "nobody else may act at all until I'm done"; a client using WATCH is claiming nothing about what other clients may do, only detecting, after the fact, whether its own specific read-then-write was still valid.

Practice

1. ▢ A script does MULTI, queues INCR counter, queues LPUSH mylist item where counter unexpectedly holds a string value (not an integer), then calls EXEC. What happens to LPUSH mylist item?

2. ▢ A client does WATCH balance, reads the current value, computes a new one, then calls MULTI/SET balance <new value>/EXEC. Another client updates balance after the WATCH but before this client's EXEC. What does EXEC return, and what should the client do next?

3. ▢ Why is WATCH/MULTI/EXEC described as optimistic concurrency control, in contrast to lesson 4's lock, which is pessimistic?

4. ▢ A team uses WATCH/MULTI/EXEC to implement what they call "a distributed lock." Is this the right tool for holding exclusive access across a multi-step critical section that involves more than a single read-modify-write? Why or why not?

5. ▢ Which claim correctly describes MULTI/EXEC and WATCH?

   • a) MULTI/EXEC rolls back every queued command if any one of them fails at execution time, exactly like a SQL transaction
   • b) MULTI/EXEC runs a queued batch without any other client's command interleaving, but doesn't roll back on a runtime error; WATCH aborts the transaction if a watched key changes before EXEC, implementing optimistic concurrency control
   • c) WATCH blocks other clients from modifying the watched key until the transaction commits
   • d) WATCH/MULTI/EXEC is a complete substitute for the distributed lock lessons 4 and 5 cover

Real-world reps

• [ ] Find (or design) a counter or balance update in a system you have access to. Check whether it's vulnerable to a lost-update race (read, compute, write, with no protection against a concurrent write in between), and whether WATCH/MULTI/EXEC would close that gap.
• [ ] Confirm, for any MULTI/EXEC usage you find, whether the assumption "if one command fails, the rest still ran" is actually accounted for, or whether the code assumes SQL-style all-or-nothing rollback that Redis doesn't provide.
• [ ] Tomorrow: read the primary source's section on transactions in full, and note its own wording for what does and doesn't get rolled back on a runtime error.

Going further

• Docs: "Data types", Redis
• Docs: "Distributed locks with Redis", Redis
• Resources

Not landing? Reread the primary source at the top, since this lesson compresses it and compression is where understanding leaks. Check the glossary for any term that felt slippery.

If the lesson itself is unclear rather than the material, that is a defect: open an issue.