A telemetry ingestion application named ThermoSense logs sensor status updates to an Amazon DynamoDB table. The table is configured with provisioned write capacity and uses SensorModel as the partition key. During a firmware update deployment, the application encounters multiple ProvisionedThroughputExceededException errors. CloudWatch metrics indicate that a specific, widely deployed sensor model is generating a high volume of writes, resulting in a hot partition. Which TWO actions should the developer take to resolve the write throttling and ensure even load distribution across partitions? (Select TWO.)
- Modify the application logic to append a random numeric suffix to the partition key value before writing the items.Answer
- Configure the AWS SDK client to use exponential backoff and jitter for request retries.Answer
- CModify the queries to use Scan operations instead of Query operations to distribute the read requests across the table.
- DIncrease the visibility timeout of the Amazon SQS queue that receives the telemetry messages to 12 hours.
- EHardcode the AWS IAM access keys directly into the application's SDK client configuration to reduce credential resolution overhead.
Answer
To resolve the throttling and key distribution issues, the developer should modify the application logic to append a random numeric suffix to the partition key value and configure the AWS SDK client to use exponential backoff and jitter for request retries.
The correct strategy combines database-level partition sharding and application-level retry patterns. Appending a random numeric suffix to the partition key distributes the write load across multiple database partitions, effectively dispersing the hot key bottleneck. Configuring the AWS SDK client to use exponential backoff and jitter ensures that the client application handles transient ProvisionedThroughputExceededException errors gracefully without overwhelming the database with immediate retries.
Step-by-Step Solution
Key Concept
Resolving DynamoDB hot partition key bottlenecks using write sharding (random suffixing) combined with client-side retry logic (exponential backoff and jitter).
Estimated Time:2m 0s