Question

Difficulty: MediumResolving DynamoDB Throttling and Key Distribution Issues

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.)

  1. Redesign the partition key schema by appending a random suffix to the WorkoutDate to distribute writes across multiple partitions.Answer
  2. Configure the AWS SDK client in the application to use exponential backoff and jitter for write retries.Answer
  3. C
    Increase the provisioned write capacity units (WCUs) of the DynamoDB table to accommodate the total aggregate throughput.
  4. D
    Modify the application to use a Scan operation instead of a Query operation to retrieve existing records before performing the write.
  5. E
    Increase the SQS queue's visibility timeout to give write consumers more time to retry throttling errors before message visibility expires.

Answer

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.

Step-by-Step Solution

1
Analyze the error and metrics.
The ProvisionedThroughputExceededException occurs despite total consumed capacity being below provisioned limits, indicating a hot partition key issue where writes are concentrated on a single partition key (WorkoutDate).
Identifying the root cause is necessary before applying the correct optimization strategy.
2
Select a partition key distribution strategy.
By appending a random suffix to WorkoutDate, the data is distributed across multiple partitions, resolving the hot partition issue.
DynamoDB partitions are based on the partition key hash value; higher entropy prevents hot spots.
3
Configure application retry mechanisms.
Implementing exponential backoff and jitter in the SDK configuration allows the application to retry failed requests efficiently without overwhelming the database.
Transient network spikes or minor partition adjustments can still cause momentary throttling, which retries can mitigate.

Key Concept

Partition key sharding and SDK retry strategies are used to resolve DynamoDB partition-level throttling issues caused by hot keys.
Rate this question