The Hot Partition
#database-oncall — Shard 3 at 100% CPU
Viral post: 50k likes/sec on one post_id. hash(post_id) % 8 always routes to Shard 3. Other 7 shards idle. Writes dropping.
The trap: Naive sharding assumes uniform traffic — celebrity keys create hot partitions.
Your task
Fix `recordLike()` and `getTotalLikes()` in `sharded_store.js`: key salting on writes (random _salt_1..10), scatter-gather sum on reads.
Book: hash sharding · Prod: salt hot keys, pay read tax to save the cluster.
Skills you'll prove
Interview Tip
When asked about NoSQL scaling, hot partitions, or skewed data, say: "Textbook sharding assumes uniform traffic, but in production, 1% of keys get 99% of traffic—like a viral post or a celebrity user. Naive hashing causes hot partitions. I solve this using Key Salting: appending a random suffix to the partition key on writes to scatter the load across multiple nodes, and using a scatter-gather pattern on reads to sum the results. It trades a bit of read complexity for massive write scalability."