The Atomicity Ladder: Command, MULTI, Lua, Functions

In one line

Redis offers four levels of atomicity: a single command, MULTI/EXEC (a queued batch that runs without interleaving), Lua scripts (logic that runs without interleaving), and Functions (Lua libraries stored on the server). None of them roll back, and pipelines aren't on the ladder at all.

0/5 · 0%

Think of it like this

A bank teller. One request ("deposit 100") is always handled whole. A signed batch of instructions handed over at once (MULTI) is executed without anyone cutting in, but the teller doesn't make decisions from it. A written procedure ("if the balance covers it, transfer, else refuse") is Lua: logic run start to finish while the queue waits.

Key ideas

01
Atomic here means isolated and all-or-nothing in execution: while a command, a MULTI block, or a script runs, no other client's command runs in between. It does not mean rollback: if the third command in a transaction fails at runtime, the first two still happened.
02
Single commands are atomic by construction (one thread). Many problems fit one command: INCR, SET NX PX, ZADD GT, LMOVE, HINCRBY, SINTERSTORE, GETDEL. Always check for a single-command solution first.
03
MULTI/EXEC queues commands and runs them together. You can't use the result of one command to decide the next inside the block, because replies only arrive at EXEC. Add WATCH for optimistic concurrency: if a watched key changes before EXEC, the whole transaction is discarded and you retry.
04
Lua (EVAL, EVALSHA) runs a script on the server with full logic: read, branch, write, return. It's the most flexible and usually the fastest (one round trip). While it runs, nothing else runs, so scripts must be short.
05
Functions (Redis 7.0+, FUNCTION LOAD, FCALL) are Lua code loaded once as a named library, persisted in RDB/AOF and replicated. Same execution model as scripts, but managed like a database artifact instead of shipped by every client.
06
Pipelining is a network optimisation: the client sends many commands without waiting for each reply. Other clients' commands can interleave, and each command is independent, so there's no atomicity. MULTI inside a pipeline gets you both: one round trip and atomic execution.
07
In Redis Cluster, every multi-key atomic operation (MULTI, Lua, Functions) requires all keys to be in the same hash slot, which is another reason to plan hash tags early.

Code & diagrams

atomicity-ladder.mermaiddiagram

Rendering diagram…

compare.txttext

                    Atomic  Can branch  Round trips  Stored on server  Blocks others
Single command      yes     no          1            n/a               for its runtime
Pipeline            no      no          1 per batch  n/a               no
MULTI/EXEC          yes     no          1-2          no                for EXEC runtime
WATCH + MULTI/EXEC  yes*    in client   2+ (retries) no                for EXEC runtime
Lua EVAL/EVALSHA    yes     yes         1            script cache      for script runtime
Functions (FCALL)   yes     yes         1            yes (persisted)   for function runtime

* aborts and retries if a watched key changed; no rollback in any case

Interview problem

The problem

Atomic, transactional, or merely batched?

For each operation, say which tool you'd use and why: (a) add 10 points to a score, (b) move a job from queue to processing, (c) transfer 50 credits from user A to B only if A has at least 50, (d) load 10,000 cache entries at startup, (e) set a product's price and bump a version counter together.

The interviewer follows up

If Redis doesn't roll back, what happens when the second command in a MULTI fails?

Explain it without notes

Explain why a pipeline is not a transaction.

What does "atomic" mean in Redis, and what doesn't it mean?

Practice

For "decrement stock only if stock > 0 and record the buyer", write the Redis solution at the lowest possible rung.

Trade-offs

↔
Lua gives full atomic logic in one round trip but blocks the server while it runs; MULTI/WATCH keeps logic in the client but needs retries under contention.
↔
Functions add deployment discipline (versioned, persisted) at the cost of an extra operational step compared to shipping scripts with the app.

Done when you can

I can place any operation on the atomicity ladder and justify the choice.
I can explain "atomic but no rollback".
I never describe a pipeline as a transaction.

Command Palette