Redis can execute Lua scripts server-side — running multiple commands as a single atomic operation. Scripts enable complex atomic logic, reduce network round-trips, and are the recommended way to do multi-step atomic operations in Redis.
# EVAL runs a Lua script; KEYS[] and ARGV[] pass keys and arguments
EVAL 1 mykey myvalue
EVAL 1 lock:resource mytoken
Scripts use redis.call() to run commands, with KEYS[] (key names) and ARGV[] (arguments) passed in. The whole script executes atomically as one unit.
✓ ATOMICITY — the ENTIRE script runs as one unit, no other commands interleave
→ perfect for read-modify-write logic that must be atomic (locks, conditional updates,
rate limiting, complex counters) — better than MULTI/EXEC for conditional logic
✓ FEWER ROUND-TRIPS — multiple operations in ONE call to Redis (less network latency)
✓ Custom LOGIC server-side — conditionals, loops, computations near the data
# load a script once, then call by its SHA hash (avoids resending the script each time)
SCRIPT LOAD "return redis.call('GET', KEYS[1])" # => returns a SHA1 hash
EVALSHA <sha> 1 mykey # run the cached script by hash
EVALSHA runs a previously-loaded script by its hash — efficient for frequently-used scripts (the script is cached server-side).
⚠️ Scripts BLOCK the server while running (Redis is single-threaded) → keep them FAST
and simple (no slow loops/operations — they'd stall ALL clients)
⚠️ Scripts should be deterministic; pass keys via KEYS[] (for cluster correctness)
→ Use scripts for short, atomic logic — not heavy computation.
Understanding Lua scripting in Redis is valuable senior-level knowledge for performing complex atomic operations, so it's useful for advanced Redis use.
The core value is atomicity for multi-step logic: a Lua script executes entirely as one atomic unit (no other commands interleave), making it the recommended way to do read-modify-write operations that must be atomic — like conditional updates, safe lock release (delete only if the token matches), rate limiting, and complex counters — often better than MULTI/EXEC because scripts support conditional logic (the transaction can't make decisions based on intermediate reads, but a script can).
This solves a real need for atomic operations more complex than single commands.
A secondary benefit is fewer network round-trips (multiple operations in one call, reducing latency) and running custom logic server-side (near the data).
Understanding EVALSHA (caching scripts by hash to avoid resending them) is a practical efficiency technique for frequently-used scripts.
Critically, understanding the cautions is important: scripts block the single-threaded server while running, so they must be kept fast and simple (a slow script stalls all clients — a real performance hazard), and scripts should be deterministic with keys passed via KEYS[] (for cluster correctness).
This awareness prevents misusing scripts for heavy computation.
Since complex atomic operations are a genuine need (locks, conditional logic, atomic multi-step updates), and since Lua scripts provide atomic, single-round-trip, server-side logic that's the recommended approach for them (with important cautions about blocking), understanding Lua scripting — how it works, why it's atomic and useful, EVALSHA caching, and the keep-it-fast cautions — is valuable senior-level knowledge for advanced Redis use, the right tool for atomic multi-step logic and a topic reflecting deeper Redis expertise.