01Why can a script safely branch on a value that it just read, while a plain queued transaction cannot?introScenarioYou need check-then-write logic where the write happens only if the value just read passes a test.AA script runs inside one atomic server-side execution boundary, so it can read a value and branch before other commands interleave.BScripts acquire a global lock for their duration, which queued transactions are not allowed to take.CTransactions could branch too, but RESP has no syntax for conditionals, so the limitation is the wire format — the queue itself could evaluate conditions if replies could be referenced.DScripts run on a replica where reads are cheap, making it safe to branch on intermediate results there.
02In cluster mode, why is hiding key names inside `ARGV` a design problem?introScenarioA script author passes key names through `ARGV` because it feels simpler than the `KEYS` array.AARGV values are not replicated with the script, so any keys named there would be lost on the replicas.BARGV entries have a small size limit, and realistic key names can easily exceed it.CIt is mostly a style concern, since the cluster discovers the touched keys during execution and routes retroactively.DCluster mode needs explicit key names to route and validate slots; hiding keys in ARGV prevents safe pre-execution routing.
03A script calls `TIME` or uses randomness to decide a write. What replication risk does that introduce?appliedScenarioA script decides whether to write a key based on the server clock and a random number it generates.AThe script will be rejected at load time, because the scripting engine compiles out all randomness sources during the compilation pass that registers the script.BRandomness slows the script down but cannot affect correctness, because replicas re-run the same bytecode.CNon-deterministic writes can make replicas or AOF replay diverge if the same script produces different effects later.DThe main risk is contention, since randomly chosen keys tend to hash into the same hot slots.
04When is a server-side function better than sending a script body with every call?appliedScenarioFive services all embed the same forty-line Lua snippet and send it with every single call.AFunctions are sandboxed more strictly than scripts, so they are required whenever the code writes keys.BA registered function is better when the code is reused because clients send a stable function name instead of a script body every time.CFunctions execute off the main thread, which makes them the right tool for long computations that scripts would block on, keeping the event loop responsive for ordinary commands.DScripts are deprecated, so any new development should use functions regardless of how often the code is reused.
05What limits would you put around scripts to protect the event loop?advancedScenarioYou are setting policy for what user-supplied scripts may do on a latency-sensitive production server.ARun scripts in a separate process pool, which removes the need for any in-script limits at all.BLimit only the script's source length in bytes, since execution time correlates with code size.CLimit runtime, memory use, blocking operations, key access declarations, and dangerous nondeterminism to protect the event loop.DDisallow all writes from scripts, which makes them pure and therefore safe for the loop automatically.
fivenines