A social platform has 1% of content receiving 90% of requests. How should adaptive caching, hot-key replication, request coalescing and partitioning work together?

Why the hot key breaks the normal model

Consistent hashing distributes keys evenly, which is exactly wrong here: it puts one extremely hot key on one node, and that node saturates while the rest of the cluster idles. Adding capacity does not help, because the bottleneck is one key on one machine, not aggregate capacity.

The layered response

• Detect hot keys continuously, with a sketch or sampled counters, rather than discovering them during an incident. A key that was cold yesterday can be hot in ninety seconds when content goes viral.
• Replicate hot keys across nodes, with clients selecting a replica at random. This trades a small amount of consistency and memory for the removal of the single-node ceiling, and it is the direct fix.
• Cache the hottest keys in-process, in each application instance. For the very top of the distribution this removes the network hop entirely and is the cheapest possible read.
• Coalesce requests per key, so a miss on a hot key produces one origin request rather than thousands.
• Consider a composite key with a random suffix for extreme cases, spreading one logical key across several physical ones — acceptable only where the value is identical across copies.

What must not be done

Do not partition by content ID and hope. Skew is the normal state of user-generated content, not an anomaly, and any design that assumes a uniform distribution will fail the moment something goes viral — which is the moment when failing is most expensive.

The write-side twin

The same skew appears on writes: a very popular item's view counter, like counter or comment count becomes a single-row contention point. The fixes are structurally different — aggregate in memory and flush periodically, or shard the counter across many rows and sum on read. Both trade exactness for throughput, and for a view count that is a trade nobody objects to.

The judgement

Design for skew from the beginning in any user-generated-content system. The uniform-distribution assumption is comfortable, standard in textbooks, and false in every social, marketplace or media product. The cost of assuming skew when it is absent is small; the cost of assuming uniformity when skew arrives is an outage during your most successful moment.