Sharding splits records across machines. Your key decides which machine owns each record, so it also decides which requests become expensive. Hashing customer IDs spreads ordinary customers, but it can't split a single customer whose traffic exceeds one partition. Marlin Logs has that exact problem.
Check the largest key, not just the average load. A timestamp range can place every new event on one hot shard. A random suffix spreads writes but makes reads visit several partitions. You also need a migration plan: a new shard doesn't receive the old records by itself. Choose the partition key from the access pattern, state the resulting query fan-out, and keep stable record identities so retries during a move can't create duplicates.