Redis transactions (via MULTI/EXEC) group multiple commands to execute atomically — all together without other commands interleaving. Combined with WATCH for optimistic locking, they handle scenarios needing multiple operations to be consistent. Redis transactions differ from SQL transactions in important ways.
MULTI # start a transaction (begin queuing commands)
SET account:1 100 # QUEUED (not executed yet)
SET account:2 200 # QUEUED
INCR counter # QUEUED
EXEC # execute ALL queued commands atomically (as one unit)
# → all commands run together, with NO other client's commands in between
MULTI begins queuing commands; EXEC runs them all atomically (no interleaving from other clients). DISCARD cancels a queued transaction.
# WATCH a key; if it CHANGES before EXEC, the transaction ABORTS (returns nil)
WATCH balance
val = GET balance # read the current value
MULTI
SET balance (val - 100) # modify based on what we read
EXEC # → if "balance" changed since WATCH, EXEC fails (returns nil)
# → retry the whole thing if it failed (optimistic concurrency control)
WATCH provides optimistic locking: if a watched key is modified by another client before EXEC, the transaction aborts — letting you safely do check-then-set operations (retry on conflict).
⚠️ Redis transactions are NOT like SQL transactions:
✗ NO ROLLBACK — if a command fails at EXEC time, OTHER commands still execute
(errors don't roll back the transaction; Redis doesn't undo). Only syntax errors
before EXEC abort the whole thing.
✓ Atomicity = commands run together without interleaving (isolation), NOT all-or-nothing
with rollback on error.
→ Often Lua SCRIPTS are used instead for complex atomic logic (a script runs atomically).
Understanding Redis transactions is valuable for performing multiple operations consistently, so it's useful knowledge — and understanding how they differ from SQL transactions is especially important to avoid incorrect assumptions.
The core capability — MULTI/EXEC grouping commands to execute atomically (all together, with no other client's commands interleaving) — addresses scenarios where multiple operations must happen as a consistent unit.
The WATCH mechanism provides optimistic locking (check-and-set): aborting the transaction if a watched key changed before EXEC, enabling safe check-then-modify operations (like decrementing a balance based on its current value) with retry on conflict — important for correct concurrent operations.
The most critical point is understanding how Redis transactions differ from SQL transactions: Redis has no rollback — if a command fails at EXEC time, the other commands still execute (Redis doesn't undo), so "atomicity" here means commands run together without interleaving (isolation), NOT all-or-nothing with error rollback.
Misunderstanding this (assuming SQL-like rollback) leads to incorrect error handling.
Knowing that Lua scripts are often used instead for complex atomic logic (a script executes atomically as a unit) is valuable.
Since consistent multi-operation execution and correct concurrency are real needs, and since Redis transactions (MULTI/EXEC with WATCH for optimistic locking) address them but with important differences from SQL (no rollback) that must be understood, understanding Redis transactions — MULTI/EXEC, WATCH-based optimistic locking, and especially the no-rollback distinction from SQL — is valuable, practically-relevant knowledge for using Redis correctly in concurrent scenarios, where understanding the differences from familiar SQL transactions is as important as the mechanism itself.