Explain what actually goes wrong in a production Redis deployment when one key holds tens of millions of elements or a value of several hundred megabytes, and how you would remodel that data.

## Why one key can hurt an entire cluster Redis processes commands one at a time on a single thread. Latency for every client is therefore the sum of the work in front of them. A key that is large in *elements* or in *bytes* turns ordinary-looking commands into long units of work that nothing can preempt — there is no per-command time slice and no yielding halfway through. ## The failure modes **O(N) commands on the serving thread.** `SMEMBERS` on a 20-million-member set, `HGETALL` on a huge hash, `LRANGE 0 -1`, `ZRANGE key 0 -1` — each walks the whole structure. At tens of millions of elements this is tens or hundreds of milliseconds of pure stall. Every other client's p99, including unrelated GETs on tiny keys, inherits it. **Freeing is also O(N).** A synchronous `DEL` of a collection must free every element. Deleting the monster to "fix" the problem can cause the very stall you were trying to avoid; the same applies when it expires or is evicted, unless the lazy-free settings move the work off the main thread. **Output buffers and disconnects.** Replies are assembled into per-client output buffers, which count toward `used_memory` and are bounded by `client-output-buffer-limit`. A few hundred megabytes of reply can breach the limit and get the client killed; worse, replicas have their own buffer class, and a big write that overruns a replica's buffer forces a disconnect and a **full resync**, which costs a snapshot, a large transfer, and can repeat if the same write pattern recurs. **Persistence and replication amplification.** Big values are copied whole into snapshots and rewrites. A frequently-modified large key also churns pages that the persistence child shares with the parent, inflating resident memory during background saves. **Cluster-level damage.** A key always maps to exactly one hash slot and therefore one shard. Consequences: the shard holding it uses disproportionate memory, so the cluster cannot be balanced by moving slots; the traffic to that key concentrates on one node, which is the classic hot-shard; and if you do try to move that slot, the migration transfers the key in a blocking operation that can exceed the configured timeout and leave the slot in a migrating state needing manual attention. **Diagnosis is indirect.** These stalls show up as an unexplained tail-latency profile. `SLOWLOG GET` will name the offending command when it is a user command — that is your best evidence — while `LATENCY LATEST` and `LATENCY DOCTOR` catch events that are not commands. Find the keys themselves with `redis-cli --memkeys` (bytes) or `--bigkeys` (element counts), preferably against a replica. ## Remodelling **Shard the key.** Split a logical collection across N physical keys by hashing the element or field: `user:events:{123}:0` … `:15`. Reads that need one element go to one shard; reads that need everything are now N bounded commands you can pipeline, and each is short enough not to stall the loop. In Cluster mode use hash tags deliberately — `{123}` keeps the parts co-located when you need them together, and *omitting* a shared tag is what lets the parts spread across shards when you want the memory and traffic distributed. **Stop reading whole keys.** Replace `HGETALL`/`SMEMBERS` with cursor-based `HSCAN`/`SSCAN` in batches, and range reads with bounded `ZRANGE`/`LRANGE` windows or `ZRANGEBYSCORE ... LIMIT`. This converts one enormous unit of work into many small ones, which is exactly what a single-threaded server needs. **Cap growth by design.** Trim lists and streams (`LTRIM`, `XADD ... MAXLEN ~`), expire per-item keys instead of accumulating into one collection, and put an explicit size ceiling in the code path that writes. **Delete safely.** Use `UNLINK` rather than `DEL`, and enable the lazy-free settings so expiry and eviction of large values also happen off the main thread. **Guardrails.** Track the largest keys periodically (a scheduled `--memkeys` on a replica), alert when any key exceeds an agreed budget — a common working rule is to keep values under about a megabyte and collections under a few tens of thousands of elements — and treat a breach as a design defect rather than a capacity issue.