Why can't application code read a key inside a Redis MULTI block and branch on its value to decide the next queued command, and what should you do when the logic genuinely needs that?

## The queueing model forbids it structurally The reason is not a missing feature; it falls out of how a Redis transaction is built. After `MULTI`, the server does not execute anything. Each command is validated and appended to a per-connection queue, and the reply is the placeholder `+QUEUED`. Execution happens only when `EXEC` arrives, and its reply is an array holding one real reply per queued command. So the timeline is: you finish building the batch, *then* results exist. A branch that needs a result would have to happen before the batch is built, from a value that does not yet exist. Client libraries reflect this honestly — the object a queued command returns is a future or placeholder that only resolves after EXEC. ``` MULTI GET balance -> QUEUED # no value here # there is nothing to compare against yet DECRBY balance 100 -> QUEUED EXEC -> 1) "250" 2) (integer) 150 # already applied, too late to reconsider ``` The DECRBY happened regardless of what the balance turned out to be. ## There is no control flow either Redis transactions are a flat list of commands. There is no conditional command, no branch, no abort-if, and no way to make one queued command's execution depend on another's outcome. The only decision point Redis offers around a transaction is WATCH, and it is binary: run the whole thing, or run none of it and tell the client to retry. This is also why "just retry inside the transaction" is not a thing, and why partial application on a runtime error cannot be prevented by clever queueing. ## Option 1: WATCH, the optimistic route WATCH implements check-and-set. The shape is: ``` WATCH balance GET balance # a real read, outside the transaction # client decides: 250 >= 100, so proceed MULTI DECRBY balance 100 EXEC # array => committed; nil => balance changed, retry ``` The server remembers the watched keys for that connection; if any of them is modified by anyone before EXEC, EXEC returns a null reply and executes nothing. The client loops: unwatch/re-read/re-decide/retry. What it costs: at least three round trips per attempt, plus more under contention, since a hot key can starve a retry loop. What it buys: the decision logic stays in your application language, with your types, your business rules and your test suite. That is a real benefit when the rule is complicated. The mechanics of WATCH — which keys are tracked, when the watch is cleared — are a topic in their own right; here it is enough to know it is the client-side answer. ## Option 2: move the logic to the server A Lua script run with `EVAL`/`EVALSHA`, or a Redis Function registered with `FUNCTION LOAD` on Redis 7.x, executes on the server as one unit. Inside, `redis.call()` returns real values immediately, so you can read, compare, branch, loop and write in one pass: ```lua local balance = tonumber(redis.call('GET', KEYS[1]) or '0') if balance < tonumber(ARGV[1]) then return 0 end redis.call('DECRBY', KEYS[1], ARGV[1]) return 1 ``` One round trip, no retry loop, no contention amplification, and — crucially — the read and the write cannot be separated by another client's command. This is why conditional logic on Redis data overwhelmingly ends up in scripts. The tradeoffs are real too: the logic is in a second language, harder to test and observe; the script blocks the server for its whole duration, so it must be short; and all keys it touches must be declared (and in Cluster must live in one hash slot). ## Option 3: use a command that already does the check Often the conditional is one Redis already implements atomically, and neither WATCH nor Lua is needed: - `SET key val NX` — write only if absent (the basis of lock acquisition). - `SET key val XX` — write only if present. - `SETNX`, `HSETNX`, `ZADD ... NX|GT|LT`, `EXPIRE ... NX|XX|GT|LT`. - `INCRBY` returning the new value, which turns "read, add, write" into one atomic step. - `GETDEL`, `GETEX`, `SET ... GET`. Reaching for a transaction when a single conditional command exists is a common over-engineering smell, and interviewers notice. ## Choosing - Unconditional batch of writes that must not interleave → MULTI/EXEC. - A single conditional that a native command expresses → that command. - Read-then-decide with rich or client-owned rules, low contention → WATCH with a bounded retry loop. - Read-then-decide that is hot, latency-sensitive, or must not retry → a Lua script or Function.