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

we're running into the classic 'hot partition' problem with dynamodb. our main table uses `user_id` as the partition key. for celebrity users with millions of followers, any activity like posting updates or receiving notifications causes a massive spike in requests to a single partition, leading to throttling and degraded performance for those users. we've tried some basic caching, but it's not enough. what are the most effective strategies for handling hot partitions caused by celebrity users or highly accessed entities? are people using write sharding, where you append a random suffix to the `user_id` for writes, or separate tables for high-volume entities, or is there a more general architectural pattern to distribute this kind of traffic?