A counter with a ceiling
The TTL is set on the first write only, so the window does not slide
- operation
- atomic-counter
Pick an operation and get a Lua script that runs it atomically. Two rules decide whether a script survives contact with production: every key goes through KEYS, and the script stays short, because it stops the whole server while it runs.
Worked setups you can load into the form above. Each one is a decision the generator makes differently, and the reason it makes it.
The TTL is set on the first write only, so the window does not slide
The comparison and the delete happen with nothing in between
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Redis Cluster routes by the keys in KEYS. A key constructed in the body is invisible to routing, so the script works on one instance and breaks when the data is sharded.
Instead:Compute key names in the client and pass them in KEYS.
Atomic means uninterrupted, not transactional. Commands that already ran stay applied when a later one raises.
Instead:Validate everything before the first write.
The whole server is stopped for the duration. Once it passes busy-reply-threshold, SCRIPT KILL will not work if the script has written.
Instead:Bound the work, or do it in the client across several calls.
The script cache is in memory and is not replicated. After a restart or a failover every call fails with NOSCRIPT.
Instead:Handle NOSCRIPT by resending the script once.
The number after the sha is the key count. Too low and the extra names land in ARGV, so the script reads empty values and does nothing, silently.
Instead:Count the keys, and let the client library do it.
Lua in Redis gives you one strong guarantee and one that people assume but do not get. The gap between them causes real data problems.
Lua executes on the same single thread that serves every client, and it runs to completion with nothing interleaved. That is exactly why a check followed by a write is safe here and is a race when done as two commands from a client.
Atomic here means uninterrupted, not transactional. If the third command raises an error, the first two have already applied and they stay applied. Redis has no rollback, for scripts or for MULTI. Do every validation before the first write.
Redis Cluster routes a script by the keys passed in KEYS. A key built inside the script body, or concatenated from ARGV, is invisible to that routing. The script works perfectly on a single instance and breaks the day the data is sharded, which is the worst possible time to discover it.
Because nothing else runs, a script that loops over a large collection stalls every other connection. Past busy-reply-threshold the only ways out are SCRIPT KILL, which fails once the script has written, and SHUTDOWN NOSAVE, which loses whatever was not persisted.
The script cache is in memory and is not replicated to a promoted replica. A client that only ever sends EVALSHA breaks at exactly the moment of a failover. Every mature client library handles the NOSCRIPT error by resending the body; confirm yours is one of them.