Hot partition problem: how do you distribute celebrity user traffic?

Dealing with hot partitions is a constant battle, especially when you have 'celebrity' users or entities that generate disproportionate traffic. We see this all the time with our user-centric data models, especially when using something like DynamoDB where `userId` is often the partition key. If a celebrity user with millions of followers suddenly posts something viral, their partition can quickly become a bottleneck, leading to throttles or increased latency for everyone interacting with their data. We've explored several mitigation strategies. Write sharding is one, where instead of `userId`, we might use `userId#timestamp` or `userId#randomSuffix` for writes, then consolidate for reads. Another approach is heavy Redis caching for read-heavy hot items. Sometimes, it even comes down to creating separate, purpose-built tables for highly active entities to isolate their traffic. It feels like there's no silver bullet, and each approach has its own tradeoffs in complexity or consistency. What's your go-to strategy for handling these kinds of hot partitions in a real-time, high-scale environment?