Challenge 3: Deploying to Cluster — Possible Solution
====================================================================

WHAT COULD BREAK: as written, the rate-limit script only ever touches
ONE key per call (KEYS[1], the single ratelimit:<clientId> key), so on
its own it's already safe on Cluster — there's only one key, so there's
no cross-slot conflict possible for THIS script as it stands.

The real risk shows up if the script were EXTENDED to also touch the
product cache key in the same EVAL call — for example, checking the
rate limit AND reading the cached product in one atomic script. If
that extended script's KEYS table included both ratelimit:<clientId>
and product:<id>, Cluster would require BOTH keys to hash to the same
slot to allow the script to run at all — and since a client ID and a
product ID are unrelated values, they would very likely hash to
DIFFERENT slots, causing Redis Cluster to reject the script outright
with a cross-slot error.

THE FIX: apply Chapter 9's hash-tag technique to force related keys
onto the same slot when a script genuinely needs to touch more than
one of them together. For example, if a script needed both a client's
rate-limit key and something else tied to that same client, naming
them ratelimit:{clientId} and clientdata:{clientId} would guarantee
both hash on clientId alone and land on the same node — the identical
discipline Chapter 9 required for any multi-key Cluster operation,
whether it's a plain multi-key command or, as here, a Lua script's
KEYS table.