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

we're building a feed service with dynamodb and running into the classic 'hot partition' problem for our celebrity users. our partition key is `userid`, which works great for 99% of users. but for a celebrity with millions of followers and a ton of activity, that single partition gets absolutely hammered with reads and writes. we've considered a few strategies: write sharding (appending a random suffix to the userid for writes, but then reads become complex), using redis as a hot cache for these celebrity feeds, or even completely separate tables for high-volume entities. what approaches have you found most effective for handling these highly skewed access patterns and celebrity problems in nosql databases like dynamodb? any pitfalls to watch out for with each strategy?