F-10 — Transactions: MULTI, EXEC, and Optimistic Locking with WATCH

Who this module is for: You need to execute multiple Redis commands as a unit — without another client's commands interleaving — but you are not sure how Redis transactions work, what "atomic" means in this context, or how to handle the read-modify-write pattern safely. This module covers MULTI/EXEC transactions, their limitations, and WATCH-based optimistic locking for conditional execution.

The Problem: Interleaved Commands

Suppose you want to transfer credits between two user accounts:

Between your read and write, another client could modify the same keys. The result: a race condition where credits appear or disappear. In PostgreSQL, you would wrap this in a transaction. In Redis, you use MULTI/EXEC.

MULTI/EXEC Transactions

Between MULTI and EXEC, every command returns QUEUED — it is added to the transaction queue but not executed. EXEC sends all queued commands to Redis, which executes them sequentially without any other client's commands interleaving.

What "atomic" means here: The commands execute in order, without interruption from other clients. It is not atomic in the database sense — there is no rollback on error.

DISCARD

Transaction Errors: Two Types

Syntax errors (caught at queue time): If a command is syntactically wrong, the error is returned at queue time. When you call EXEC, the entire transaction is discarded:

Runtime errors (caught at execution time): If a command is syntactically valid but fails at runtime (e.g., type mismatch), the error is returned for that specific command, but the rest of the transaction continues:

key3 was set successfully despite key2's error. Redis transactions do not roll back on runtime errors. This surprises most engineers coming from SQL databases. The reasoning: most runtime errors in Redis are programming bugs (wrong type), not transient failures. There is no mechanism to "undo" an already-executed SET.

The Critical Limitation: No Conditional Logic Inside Transactions

You cannot read a value inside MULTI/EXEC and use it to make a decision:

All reads inside a transaction return QUEUED — the actual values are only available after EXEC returns the full result array. By that time, you have already submitted the writes.

This means the naive MULTI/EXEC approach cannot implement "check balance then debit" — it can only implement "debit unconditionally as an atomic unit."

For conditional operations, you need WATCH.

WATCH: Optimistic Locking

WATCH implements optimistic concurrency control. It monitors one or more keys and makes the subsequent transaction conditional: if any watched key is modified by any client between WATCH and EXEC, the transaction is aborted (returns nil instead of executing).

The WATCH + MULTI + EXEC Pattern

When EXEC returns nil, it means the watched key changed — your reads are stale. The correct response is to retry the entire operation from the beginning: re-read, re-apply logic, re-attempt the transaction.

Safe Balance Deduction in Node.js

The retry loop is essential. Without it, a contested key would simply fail after the first concurrent modification.

When WATCH Retries Become a Problem

On a hot key (many concurrent writers), every client watches and retries. Under high contention, most attempts fail and retry repeatedly — this is the same thundering herd problem as cache stampedes. Symptoms:

• CPU spikes on the application side (lots of retries)
• Redis shows many EXEC calls but few actual writes
• Latency increases proportionally to the number of concurrent writers

For hot counters or balances with many concurrent writers, Lua scripts are the correct solution (covered in A-2). A Lua script executes atomically in a single pass without the watch-retry cycle.

Transactions in ioredis

ioredis chains transaction commands via .multi():

With WATCH:

What Transactions Do Not Solve

No Read-Your-Own-Writes Inside a Transaction

Commands inside MULTI/EXEC execute sequentially, but you cannot use the result of one command to feed into the next (because all results come back together after EXEC):

For read-then-write logic, use Lua scripts.

No Cross-Key Atomicity in Redis Cluster

In Redis Cluster, keys are distributed across nodes based on their hash slot. A MULTI/EXEC transaction can only be atomic across keys on the same node. If key1 and key2 are on different nodes, a transaction spanning both will fail.

Solution: use hash tags to co-locate related keys on the same slot:

For cross-key atomicity in Cluster, use Lua scripts (A-2) with KEYS array containing all keys (Cluster routes based on the first KEYS argument).

Transaction Use Cases

Good fits for MULTI/EXEC:

• Atomic writes across multiple related keys (no reads needed mid-transaction)
• Counter reset + audit log: GETDEL counter + LPUSH audit_log
• Multi-key set with expiry: set several keys and expire them together
• Batch updates where partial application would be incorrect

Poor fits for MULTI/EXEC (use Lua instead):

• Read-modify-write patterns with conditional logic
• High-contention keys with many concurrent writers
• Complex multi-step operations that depend on intermediate results

Summary

• MULTI begins a transaction queue; EXEC executes all queued commands atomically; DISCARD clears the queue
• "Atomic" means no other client's commands interleave — not that the transaction rolls back on error
• Syntax errors at queue time abort the whole transaction; runtime errors in EXEC skip that command and continue
• You cannot use a read result inside a transaction to make a conditional decision
• WATCH key enables optimistic locking: if the watched key changes before EXEC, the transaction returns nil
• Always retry on nil from EXEC — read the current state again and re-attempt
• High-contention WATCH scenarios → use Lua scripts for lock-free atomic operations
• In Redis Cluster, transactions only work across keys on the same hash slot — use hash tags to co-locate keys

Next: F-11 — Caching Patterns: Cache-Aside, Write-Through, Write-Behind, and Read-Through — the four caching strategies, when to use each, and the consistency trade-offs that no tutorial mentions.