A fitness tracking application named FitPulse records real-time workout metrics from users' smartwatches into an Amazon DynamoDB table. The table is configured with provisioned read and write capacity. The partition key is `WorkoutDate` (formatted as YYYY-MM-DD), and the sort key is `UserId`. During peak hours (e.g., weekday evenings), the application experiences a high volume of write failures, and the backend logs display `ProvisionedThroughputExceededException` errors, even though the total consumed write capacity is well below the table's provisioned limit. Which combination of actions will resolve this issue? (Select TWO options.)
- Redesign the partition key schema by appending a random suffix to the WorkoutDate to distribute writes across multiple partitions.Cevap
- Configure the AWS SDK client in the application to use exponential backoff and jitter for write retries.Cevap
- CIncrease the provisioned write capacity units (WCUs) of the DynamoDB table to accommodate the total aggregate throughput.
- DModify the application to use a Scan operation instead of a Query operation to retrieve existing records before performing the write.
- EIncrease the SQS queue's visibility timeout to give write consumers more time to retry throttling errors before message visibility expires.
Cevap
Redesign the partition key schema by appending a random suffix to the WorkoutDate to distribute writes across multiple partitions, and configure the AWS SDK client in the application to use exponential backoff and jitter for write retries.
The application is encountering partition throttling because using a low-cardinality value like WorkoutDate as the partition key concentrates all writes on the same day to a single physical partition (a hot key issue). Appending a random suffix to the WorkoutDate distributes writes across multiple partitions. Additionally, configuring the AWS SDK with exponential backoff and jitter helps the application gracefully handle transient throttling errors and retry requests.
Adım Adım Çözüm
Anahtar Kavram
Partition key sharding and SDK retry strategies are used to resolve DynamoDB partition-level throttling issues caused by hot keys.