Cache Sharding

The Mechanics

 shard = subset of the keyspace owned by one node:

 key ──hash──► slot ──map──► node

 redis cluster:  16384 fixed slots, distributed across nodes
   node A: slots 0-5460
   node B: slots 5461-10922
   node C: slots 10923-16383

 why FIXED slot count: growing from 3→6 nodes moves SLOTS,
 not re-hashes every key — only ~half the slots migrate,
 each carrying its keys intact.

Hash-Tag for Multi-Key Operations

 operations spanning keys (MGET, transactions, Lua) require
 same-shard keys. hash tags force co-location:

 user:{912}:profile
 user:{912}:sessions        ← {912} hashes together → same shard

 use deliberately for entity groups;
 overuse creates giant unshardable blobs of keyspace.

Placement Strategies Compared

Strategy	Mechanism	Weakness
Modulo N	hash % node_count	Full remap on resize
Slot table	Fixed slots → nodes	Needs slot migration protocol
Consistent ring	Ring positions + vnodes	Hotspot tuning via vnodes
Range	key ranges to nodes	Skew risk; ordered scans possible

 modern default: SLOT TABLE (redis) or RING+VNODES (cassandra-
 style). both make resize incremental — the property that matters.

Resharding Without a Stampede

 adding capacity while live:

 1. new node joins, claims half the slots of an existing node
 2. MIGRATION: keys move in batches (redis MIGRATECOPY per key)
    during which:
    - asking client gets ASK/MOVED redirect → follows to new owner
    - dual-lookup window handled by smart clients automatically
 3. slot map update propagates; redirects taper to zero

 failure modes to watch:
 - migration under write-heavy load → latency spikes on moved slots
 - batch migrations small + throttled; off-peak for big moves
 - CLIENT topology refresh lag → brief redirect storms (fine)

Shard Count and Sizing

 more shards:
 + aggregate memory/throughput scale linearly-ish
 + smaller blast radius per shard loss
 − connection fan-out from every client pod (pods × shards!)
 − operational surface grows

 rule-of-thumb starting points:
 - keep per-node memory ≤ ~25GB (fork/latency headroom)
 - size so ONE shard's loss is absorbable (replica promotion +
   partial refill) without breaching db capacity
 - don't shard below need: 2×32GB beats 8×8GB operationally

The Rebalancing Trap

 hash distribution ≠ load distribution:

 skewed key popularity → some shards hotter regardless of
 uniform hashing. monitor PER-SHARD cpu/memory/qps;
 hot-key mitigations (own lesson) apply WITHIN sharding —
 sharding spreads keys, not their popularity.

Interview Framing

“Scale the cache to 10TB” expects: slot-based sharding with numbers (“16384 slots, ~25GB/node → hundreds of nodes if needed”), hash-tag co-location for entity groups, resize mechanics with MOVED/ASK redirects named, and the skew caveat closing. Candidates quoting consistent hashing without explaining RESIZE behavior miss what the concept exists for.