A healthcare startup collects continuous heart rate data from thousands of wearable medical patches. The patches stream telemetry data to an Amazon Kinesis Data Stream that has shards. The stream is experiencing periodic `ProvisionedThroughputExceededException` errors during peak hours, and analysis reveals that a single shard is receiving over of the traffic because the developer chose `device_manufacturer` as the partition key. Which of the following changes to the partition key should the developer implement to resolve the throttling and distribute the load evenly across all shards?
- Change the partition key to a high-entropy value such as a combination of device_id and the telemetry timestamp.Answer
- BChange the partition key to a static string value like heart_rate_telemetry to group all incoming records.
- CReplace the Kinesis stream with an Amazon SQS queue and reduce the message visibility timeout below the average message processing time.
- DMove the processing Lambda function to a private VPC subnet without configuring a NAT Gateway or VPC endpoint.
Answer
Change the partition key to a high-entropy value such as a combination of device_id and the telemetry timestamp.
The correct answer resolves partition hotness by switching to a key with high entropy. By combining the unique device identifier with the event timestamp, the developer ensures a uniform distribution of hashed keys across the shards, mitigating ProvisionedThroughputExceededException errors.
Step-by-Step Solution
Key Concept
Selecting high-entropy partition keys to prevent hot shards in Kinesis Data Streams.
Alternative Method
Using an explicit hash key (ExplicitHashKey) in the PutRecord/PutRecords API calls to directly assign records to specific shards.
Estimated Time:1m 30s