A manufacturing company collects IoT device data via Amazon Kinesis Data Streams. The payload contains device ID, capture date, measurement type, measurement value, and facility ID. The producer uses facility ID as the partition key. The operations team observed many WriteThroughputExceeded exceptions: some shards are overloaded while others are idle. How should the company resolve this hot-shard issue?

Changing the partition key to a randomly generated key (e.g., UUID) distributes records more evenly across all shards, preventing a single shard from becoming overloaded. This resolves the hot-shard issue by maximizing shard utilization and reducing WriteThroughputExceeded exceptions. Increasing the number of shards might temporarily alleviate the issue but doesn't solve the underlying problem of uneven data distribution caused by a skewed partition key. Archiving data on the producer side is irrelevant to Kinesis throughput issues. Changing the partition key to capture date would likely exacerbate the hot-shard problem, as all devices would write to the same shard for a given date, leading to even more severe bottlenecks.