A celebrity is not a hash problem

Before you start

• Partitioning

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

  Open lesson

Why it matters

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.

Timelines are partitioned by viewer id. One viewer is fine. The problem is a celebrity post that writes every viewer, and one viewer whose home is read constantly is a different hotspot.

Viewer hashing cannot shrink a 20-million-write celebrity post or split one 50,000-read viewer key. Store the celebrity post once and merge it on home reads; replicate the shared-screen viewer’s hot result while normal homes stay on one partition.

The celebrity write already spreads across viewer partitions, but its total remains 20 million. Store that post once in the celebrity’s recent list and merge it into each follower’s home when they read; ordinary authors continue using the normal timeline path.

The 50,000-read shared-screen viewer is a different shape: every request names the same viewer key. Cache its rendered home in several places or add read copies for that key. This multiplies read capacity, but updates must invalidate or refresh those copies.