Explain how splitting one heavily-read cache entry into several Redis keys with different suffixes (for example `product:123:0` through `product:123:9`) relieves load, and what that technique costs you.

## The idea A hot key cannot be load-balanced because placement is a pure function of the key name. So change the name. Instead of one `product:123`, keep N replicas of the same value under N different names, and have each reader consult one of them. ``` write: SET product:123:0 <v> EX 300 SET product:123:1 <v> EX 307 ... (N copies) read: GET product:123:<random 0..N-1> ``` This is sometimes called suffix sharding, key salting, or fan-out caching. ## Why it works — and the condition that makes it work In Redis Cluster the slot is `CRC16(key) mod 16384`. Adding a suffix changes the hash, so the copies scatter across slots and — as long as slots are distributed over several masters — across nodes. Each node then has its own command thread, its own NIC and its own CPU, so aggregate capacity for that logical entry multiplies. The critical condition: **do not use a hash tag**. Redis Cluster hashes only the substring inside `{...}` when a key contains braces, so `{product:123}:0` and `{product:123}:1` deliberately land in the *same* slot — the exact opposite of what you want here. Hash tags exist to co-locate keys for multi-key operations; using them while splitting a hot key silently defeats the whole exercise. Conversely, if you are on a single non-clustered instance, splitting has almost no effect on CPU: same process, same thread. It can still slightly help by breaking up per-key contention in some client-side structures, but the honest answer is that splitting is a cluster technique (or a technique for spreading across several independent Redis instances). ## Choosing the suffix at read time Two strategies: - **Random per request** — perfectly even spread, but every application instance touches every copy, so no locality and each instance's near cache (if any) sees all N. - **Sticky per instance/thread** — e.g. `hash(instance_id) mod N`. Traffic is even in aggregate when instance count ≫ N, and each instance always talks to the same copy, which pairs nicely with a local cache and gives more predictable connection routing. The risk is uneven spread when N is close to the number of instances. Choose N from the arithmetic, not from a round number: if one node can serve 100k rps for this value and you need 400k, N=5 or 6 gives headroom. Bigger N multiplies memory and write cost for nothing. ## The write path is where it gets expensive Updating or invalidating means touching all N keys. - In cluster mode the copies are in different slots, so a single `MULTI`/`EXEC` or a single `EVAL` cannot cover them — cross-slot multi-key commands are rejected. You issue N separate commands (pipelined per node, ideally). - That is not atomic. A crash or a partial failure mid fan-out leaves a mix of old and new copies, and a reader picking at random gets a coin flip. For a cache this is usually acceptable (it heals at the next write or TTL) but it must be a conscious decision — never split a key whose readers require a consistent view across successive requests. - Deleting is the same problem: an invalidation that misses one copy leaves stale data alive until its TTL. Because writes cost N× and reads cost 1×, splitting is right for read-hot, write-rare entries and wrong for write-hot ones. ## TTL correlation If all N copies are written in the same instant with the same TTL, they expire in the same instant, and the very key you split because it was hot now produces N simultaneous misses and N recomputes. Add a per-copy jitter to the TTL (a few percent) so expiries scatter, and combine with a recompute guard on the miss path. ## Hot *write* keys The mirror-image technique exists for counters: instead of `INCR views:123`, do `INCR views:123:<random 0..N-1>` and sum the N shards on read (`MGET` plus addition, or a Lua script if they are co-located — here you *do* want a hash tag so the sum is one round trip). Writes divide by N; reads cost N reads. That is a good trade when writes vastly outnumber reads, and the reverse of the read-splitting trade. ## Operating it Splitting is targeted surgery, not a schema. Keep the set of split keys in configuration (or derive it from your hot-key detection pipeline), keep N small, document the fan-out in the write path so the next engineer does not add a fifth writer that updates only one copy, and add a metric for "copies disagreed" if correctness matters. Before reaching for it, check the cheaper options: shrink the value, add a one-second in-process cache, or route reads to replicas — all of which avoid the write-path complexity entirely.