Hot-Key Mitigation

Foundations

So far, a good key spread the load evenly. Now, what if one key is so popular that no key choice spreads it: one record written to millions of places, or one key read 50,000 times a second?

First classify the hotspot. A hot write fans one change out to many targets; the fix is to store it once and merge it in when readers ask, so the write stays one row. A hot read hammers one key; the fix is to copy that key into several caches or read replicas, so many nodes share the reads. Ordinary keys keep the normal path.

Take a system where most records reach 100 readers. One record must reach 10 million: copying it 10 million times is the hot write, so store it once and merge it at read time. One key read 50,000 times a second is the hot read, so cache it on five nodes, about 10,000 reads each.

• Partitioning

  Keys are spread over nodes by hashing. That lesson covers the ring.

  Open lesson

Case Scenario

To see how hot keys need their own fixes, consider home timelines in a feed like X's, partitioned by viewer id: a celebrity post must reach 20 million viewer timelines, a hot write, while one shared-screen viewer whose home is read 50,000 times a second is a hot read. Store the first once; copy the second.

Viewer-id partitioning keeps an ordinary home read in one place, yet two extreme cases remain. A celebrity post targets 20 million different viewer timelines, while one shared-screen viewer can send 50,000 reads per second to a single key. The normal user’s home must stay a one-partition read while neither hotspot overwhelms its owning partitions.