One Redis key is read about 50,000 times per second while being rewritten only occasionally, and it is saturating the node that owns it. You are considering adding read replicas of that Redis master so reads can be served from them. Work through the capacity arithmetic: what does each added replica actually buy you for that one key, what would change if the same key were write-hot instead of read-hot, and how does the cost per unit of relief compare with splitting the entry into several suffixed Redis keys or putting a sub-second in-process cache in front of Redis?

## What the replica actually buys for one key A Redis master executes commands on a single core and answers them over one network interface. A hot key's throughput ceiling is therefore the ceiling of exactly one node. A replica is a separate Redis process, normally on a separate host, holding a full copy of the dataset — so the hot key is present on it, and any read it answers consumes *its* core and *its* NIC rather than the master's. That gives the arithmetic: with one master and N replicas able to serve reads, the read budget for that single key is roughly (N+1) times a single node's budget. It scales linearly and it changes nothing about your key names or data model — only read routing. The connection-level mechanics (cluster clients must issue `READONLY`, and because replication is asynchronous a replica read can return a slightly older value) are owned by the replication topic — see `db-redis-replication-async-stale-replica-reads` — and are not re-derived here. ## Size the ceiling before you size the fleet People reach for replicas assuming CPU is the limit. For a hot key it usually is not. Compute egress first: **bytes/sec = value size x reads per second** - 20 KB value x 50,000 rps = ~1 GB/s = ~8 Gb/s of application payload, before protocol and TCP overhead. A 10 Gb NIC is already at its practical limit; a 1 Gb NIC was exceeded 8x ago. - The same 50,000 rps against a 200-byte value is 10 MB/s — nowhere near a NIC, so there the limit really is command CPU (and the fix might just be pipelining or fewer round trips). So for the 20 KB case you need roughly four to five serving nodes for bandwidth alone, and each additional replica adds one NIC's worth of headroom. Note what the same formula implies about the cheapest lever: shrink the value. Trimming a 20 KB blob to 4 KB (drop unused fields, compress, split the document so callers fetch only what they need) removes 80% of the problem without buying a single machine, and every other technique then works on a smaller number. A second ceiling worth checking is per-connection and per-client fan-out: thousands of clients each polling the key also cost accept/read syscalls and output-buffer memory on the serving node, which replicas divide the same way. ## Why a write-hot key gains nothing — and loses a little All writes for a key go to the single master that owns it; replicas are read-only copies. So if your hot key is a counter being `INCR`ed 50,000 times a second, adding replicas gives zero relief on the hot path. Worse, the master must propagate every write to every replica. Master replication egress is approximately: **write rate x propagated size x number of replicas** For a large value rewritten often this dominates: a 1 MB value rewritten 10 times a second across 5 replicas is ~50 MB/s of pure replication traffic leaving the master, competing with the client traffic you were trying to protect. Each replica also costs the master a client buffer and, on (re)connection, a full sync that briefly consumes CPU, disk and bandwidth. A write-hot key needs a different family of fixes — sharding the write across suffixed keys and summing on read, or aggregating in the application and flushing periodically — not replicas. ## Cost per unit of relief, compared Rank the three options by relief bought per dollar and per unit of operational complexity: - **Sub-second in-process (near) cache.** Each application instance holds the value locally with, say, a 200 ms TTL. Its Redis read rate for that key collapses to 5 GET/s regardless of user traffic; 40 instances produce 200 rps total instead of 50,000 — a ~250x cut for zero new infrastructure. The price is bounded staleness of one TTL and per-instance memory. Highest leverage by a wide margin, and it composes with everything else. - **Key splitting / suffix sharding.** Write the same value under K suffixed keys and have each reader pick one; because the suffixes hash to different slots they can land on different masters, so you get up to Kx read capacity *and* it relieves write pressure when writes are sharded too. Memory cost is only K copies of that one value, not K copies of the dataset. The price is application logic, a fan-out on invalidation (you must expire all K), and skew if suffixes collide onto the same shard. - **Read replicas.** Each unit of read capacity costs a full copy of the *entire* dataset in RAM plus a host, even though you only wanted more throughput on one key. You also must size for N-1, because a replica can be promoted and leave the read pool. Replicas earn their keep when you wanted the availability anyway, when the value genuinely cannot be held in-process, or when the read pressure is spread over so many keys that a per-key trick is impractical. A defensible order of attack for a read-hot key: shrink the value, add a short-TTL near cache, split the key, then add replicas — and re-measure `value size x rps` after each step, because the ceiling moves.