What are Redis transactions and how do MULTI/EXEC work?
Understand Redis transactions with MULTI, EXEC, DISCARD and WATCH, why there is no rollback, and how optimistic locking prevents race conditions.
Expected Interview Answer
A Redis transaction groups several commands so they execute as a single isolated unit: MULTI starts the block, commands are queued rather than run, and EXEC runs them all sequentially with no other client's commands interleaved.
After MULTI, each command is queued and returns QUEUED instead of executing. Calling EXEC runs the whole queue atomically in order; DISCARD throws it away. Optimistic locking is added with WATCH: if any watched key is modified by another client before EXEC, the transaction aborts and EXEC returns nil, letting you retry. Importantly, Redis transactions have no rollback — if a command fails at runtime (for example, a wrong type operation), the other commands still execute; only syntax errors detected at queue time abort the whole transaction.
- Groups commands into one isolated, non-interleaved execution
- WATCH enables optimistic concurrency control without locks
- Commands run in a deterministic queued order
- DISCARD cleanly abandons a queued transaction
- Predictable behavior with no partial interleaving from other clients
AI Mentor Explanation
Think of an over as a fixed block of six deliveries bowled by one bowler with no other bowler allowed to sneak a ball in between. Once the umpire signals the over to begin, those six balls are played out in sequence uninterrupted — that uninterrupted, ordered block is exactly how MULTI/EXEC runs its queued commands.
Step-by-Step Explanation
Step 1
Optionally WATCH keys
Use WATCH on keys whose values the transaction depends on, enabling an optimistic check before commit.
Step 2
Start with MULTI
Issue MULTI to begin the transaction; subsequent commands are queued, each returning QUEUED.
Step 3
Queue commands
Send the commands that make up the unit of work; Redis stores them without executing yet.
Step 4
Commit with EXEC
EXEC runs the queued commands atomically in order; if a watched key changed, EXEC returns nil and nothing runs.
Step 5
Handle abort or discard
On a nil EXEC, retry from WATCH; use DISCARD to abandon a queued transaction without executing it.
What Interviewer Expects
- Knowing MULTI queues and EXEC executes the batch atomically
- Explaining WATCH as optimistic locking that aborts on change
- Awareness that Redis transactions have no rollback
- Distinguishing queue-time syntax errors from runtime errors
- Understanding no other client's commands interleave during EXEC
Common Mistakes
- Assuming Redis rolls back completed commands when one fails
- Thinking commands execute immediately after MULTI instead of queuing
- Confusing MULTI/EXEC isolation with pipelining's network batching
- Forgetting WATCH is needed for check-and-set concurrency
- Not retrying the transaction when EXEC returns nil after an abort
Best Answer (HR Friendly)
“A Redis transaction lets you group several commands so they run together as one uninterrupted unit. You start with MULTI, the commands get queued, and EXEC runs them all in order; WATCH can cancel the transaction if the data it depends on was changed by someone else first.”
Code Example
# Optimistic check-and-set on a balance
WATCH account:1:balance
# read current value in the client, decide new value
MULTI
DECRBY account:1:balance 50
INCRBY account:2:balance 50
EXEC
# EXEC returns the array of replies, or (nil) if
# account:1:balance was modified by another client
# after WATCH -> then retry from WATCH.Follow-up Questions
- Does Redis roll back a transaction if one command fails?
- How does WATCH implement optimistic locking?
- What is the difference between MULTI/EXEC and pipelining?
- What does EXEC return when a watched key was modified?
- When would you use a Lua script instead of a MULTI/EXEC transaction?
MCQ Practice
1. What does a command return after MULTI while inside a transaction?
Between MULTI and EXEC commands are queued rather than executed, and each returns QUEUED until EXEC runs them.
2. What happens if a watched key is modified before EXEC?
WATCH provides optimistic locking: if a watched key changes, EXEC aborts and returns nil so the client can retry.
3. How does Redis handle a runtime error in one command inside EXEC?
Redis transactions have no rollback; a runtime error on one command does not stop the others from executing.
Flash Cards
What do MULTI and EXEC do? — MULTI starts a transaction and queues commands; EXEC executes the queued commands atomically in order with no interleaving.
What is WATCH used for? — Optimistic locking: if a watched key is modified before EXEC, the transaction aborts and EXEC returns nil so you can retry.
Do Redis transactions support rollback? — No. A runtime error in one queued command does not undo the others; only queue-time syntax errors abort the whole transaction.
How is MULTI/EXEC different from pipelining? — MULTI/EXEC provides atomic, isolated execution; pipelining only batches commands over the network with no atomicity guarantee.