A page render needs 200 objects that are individually cached in Redis. How do you fetch them without paying 200 round trips, and how do you handle the subset that comes back missing?

## The problem with a loop of GETs A cache lookup is microseconds of server work wrapped in a network round trip that is typically tens to hundreds of microseconds inside a datacenter, and milliseconds across zones. Two hundred sequential GETs means 200 round trips, and that latency is entirely additive: the request spends most of its time waiting, not computing. This is the cache-layer version of the N+1 query problem. There are two ways to collapse it, and they solve slightly different things. ## MGET `MGET key1 key2 ... keyN` returns an array of replies in **argument order**, with a `nil` in every position whose key was absent. That positional correspondence is the whole API: you keep your ordered list of ids, zip it against the reply, and split into hits and misses. MGET is one command, so it executes atomically with respect to other commands — you get a consistent snapshot of those keys at a single point in time. It is also `O(N)` in the number of keys, executed on Redis's single main thread. That is cheap for hundreds of keys and dangerous for hundreds of thousands: one giant MGET is a head-of-line blocker for every other client on that node, and it also produces one very large reply that must be allocated in the output buffer. Chunk large fan-outs into batches of a few hundred to a couple of thousand. ## Pipelining Pipelining is the more general tool: the client writes many independent commands to the socket without waiting for each reply, then reads all the replies. It works for heterogeneous commands (GET, HGETALL, ZSCORE mixed together), which MGET cannot do since MGET only reads string keys — calling it on a hash or list yields nil for those positions rather than an error. Pipelining is *not* atomic: other clients' commands can interleave between your pipelined commands. If you need atomicity you need MULTI/EXEC or a script, which is a separate topic. For cache reads, atomicity across the batch is almost never required. Rule of thumb: MGET when everything is a plain string key you can name up front; a pipeline when the shapes differ or when you are mixing reads and writes. ## Handling the miss subset The mistake that eats the benefit is fixing misses one at a time. If 30 of 200 keys missed, do **one** database query for those 30 ids, not 30 queries. The whole point of batching the cache read is to end up with a single batched load behind it. Then write back. This is where people reach for `MSET` and regret it: MSET sets multiple keys atomically but has **no** TTL option, so every entry it writes is immortal unless you follow with N `EXPIRE` calls — which is both more commands than a pipelined SET and non-atomic in exactly the dangerous way (crash between MSET and EXPIRE leaves immortal keys). Pipeline `SET key value EX ttl` instead: same single round trip, every key gets its expiry atomically with its value. A subtlety worth mentioning: giving every key in a batch the identical TTL means the whole batch expires simultaneously, which produces a synchronized miss wave later. Spreading expiries is TTL-policy territory, but knowing the batch write is where it originates is part of understanding this pattern. ## Cluster constraints Redis Cluster shards by hash slot (CRC16 of the key, or of the substring inside `{}` if a hash tag is present, modulo 16384). Any multi-key command must have all its keys in **one** slot, otherwise the node replies `CROSSSLOT Keys in request don't hash to the same slot`. So a naive 200-key MGET fails on a cluster. Options: (a) use a cluster-aware client that splits the MGET by slot, issues the parts concurrently to the owning nodes, and reassembles the result in argument order — most mature clients do this; (b) use hash tags to co-locate keys that are always fetched together, at the cost of skewing slot distribution; (c) fall back to a pipeline of single-key GETs routed per node, which is still one round trip per node rather than per key. Single-node and Sentinel deployments have no such restriction. ## Partial failure and result assembly With a pipeline, individual commands can fail independently (a WRONGTYPE, for example) — read every reply and check it rather than assuming success. With MGET, an error fails the whole command. Either way, the fallback stays the same as any cache-aside path: anything you did not get from Redis, you get from the database, and a Redis-level failure degrades to "everything missed". Finally, measure the hit ratio **per batch position**, not just globally: a page that reliably has one always-missing key still pays a database round trip on every render, and that is invisible in an aggregate 97% hit rate.