A Redis Script Is Atomic While It Blocks Other Work

Suppose a voice application gives each session a small quota for live transcription. Two workers may receive chunks at nearly the same time. A client-side GET, comparison, then DECRBY leaves a gap in which both workers can accept the same remaining quota. A short Redis Lua script can make that decision in one server-side execution.

local left = tonumber(redis.call('GET', KEYS[1]) or '0')
local cost = tonumber(ARGV[1])
if left < cost then return 0 end
redis.call('DECRBY', KEYS[1], cost)
return 1

Pass the quota key through KEYS[1] and a validated positive integer cost through ARGV[1]. Redis’s Lua scripting guide says scripts execute atomically: another client cannot observe this script halfway through its read and update. It also says server activities are blocked for the script’s entire run. The quota example is safe only if the surrounding application defines what a missing key means and initializes quotas accordingly.

Bound the amount of work

A script that loops through every pending transcription chunk still holds the server while it walks the list. Other sessions’ cache reads and writes wait, even when they touch unrelated keys. Keep the script’s input size and command count bounded; move audio processing, model calls, and broad scans to workers outside Redis. Use the script for the small state transition that must be indivisible.

The Lua guide requires every accessed key name to be supplied explicitly as a key argument. Generating key names inside the script is especially troublesome for cluster routing. Parameterize values through ARGV instead of generating new script text for each session. This avoids creating unnecessary cached scripts. The EVAL command reference documents a version boundary: before Redis 7.4, its cache lacked script eviction; Redis 7.4 and later evict its least recently used scripts when that cache reaches a size threshold.

There is an operational edge to long scripts. Redis describes SCRIPT KILL as available only while a script has made no dataset changes. Once a runaway script has written data, that escape is unavailable without disrupting the server. The programmability guide explains that when a script exceeds the configured slow-script threshold, Redis logs it and replies with BUSY errors to ordinary commands while the script continues. The threshold does not automatically terminate the script, so the algorithm still needs a bound.

For quota admission, cap the work to one key and one conditional update, validate cost before invoking it, and measure the latency of the complete call under the largest allowed input. If the operation needs to traverse an unbounded queue, redesign the queue operation before putting it inside EVAL.