Redis Atomicity Toolkit: Lua Scripts, Pipelining, and MULTI/EXEC

Redis offers three different mechanisms for grouping commands, and they solve different problems. Conflating them — especially treating pipelining as a transaction — is one of the most common mistakes I see.

Pipelining — throughput, not atomicity

• Pipelining sends multiple commands in one network round trip and reads all responses back together; it's purely a latency optimization
• There's no atomicity — other clients can execute commands between any two of mine; if I pipeline GET counter; INCR counter, another client can modify counter in between
• Use it when you need to bulk-load 10,000 keys or fan out 100 reads — anywhere throughput matters and ordering doesn't

MULTI/EXEC — atomic command groups

• MULTI/EXEC queues commands on the server and executes them as one atomic block — no other client's commands interleave
• Two surprises: there's no rollback (a runtime error in one queued command doesn't undo the others), and there's no conditional logic (you can't decide what to queue based on values read during the transaction)
• WATCH adds optimistic concurrency — watch a key, read it, build a transaction based on the value, EXEC; if anyone modified the key in between, EXEC returns nil and you retry
• Useful for simple atomic groups; under contention, the retry loop can become wasteful

Lua scripts — atomicity with logic

• Lua scripts run server-side as a single atomic operation; they can read values, branch on them, compute, and write results — all without interleaving
• This is the only way to express "check the counter; if below the limit, increment and set TTL; otherwise reject" as one atomic operation
• Critical caveat: Redis is single-threaded, so a Lua script blocks every other client until it completes; keep scripts short (microseconds), deterministic, and pass keys via the KEYS array for cluster compatibility
• Spring Data Redis caches scripts via EVALSHA automatically; on Redis 7+, prefer the new Functions API over ad-hoc EVAL

The decision in practice: pipelining for bulk operations without atomicity, MULTI/EXEC for simple unconditional atomic groups, Lua for anything requiring read-then-write decisions. For rate limiters and distributed locks, the answer is almost always Lua.