Question

Difficulty: HardResolving DynamoDB Throttling and Key Distribution Issues

An agricultural IoT platform named AgriGrow records hourly soil telemetry data from millions of sensors deployed across global farms. The data is written to an Amazon DynamoDB table with a partition key of `FarmID` (UUID) and a sort key of `Timestamp` (ISO 8601 string). During a sudden regional weather event, the platform experiences a massive surge in sensor writes. The application starts receiving `ProvisionedThroughputExceededException` errors. CloudWatch metrics indicate that the table's total consumed Write Capacity Units (WCUs) are far below the total provisioned write capacity. The developer finds that a single large farm has thousands of active sensors writing simultaneously, creating a hot partition. The telemetry client currently fails immediately when a write is throttled. Which TWO actions should the developer take to resolve the write throttling and minimize client-side errors? (Select TWO.)

  1. Append a random numeric suffix to the `FarmID` partition key during write operations to distribute the write volume across multiple physical partitions.Answer
  2. Configure the application client's AWS SDK to implement exponential backoff and jitter for request retries.Answer
  3. C
    Increase the provisioned Write Capacity Units (WCUs) of the DynamoDB table to absorb the peak write throughput of the hot partitions.
  4. D
    Modify the application retrieval logic to use `Scan` operations with a filter expression instead of `Query` operations to read the telemetry records.
  5. E
    Increase the Amazon SQS visibility timeout of the queue processing the telemetry events to allow more time for DynamoDB writes to succeed.

Answer

The developer should append a random numeric suffix to the partition key during write operations to distribute the write traffic, and configure the application SDK client to use exponential backoff and jitter for retrying throttled requests.
The correct actions are to append a random numeric suffix to the partition key (write sharding) and configure exponential backoff and jitter in the SDK client. In DynamoDB, each physical partition has a maximum write limit of 10001000 WCUs per second. When writes to a single partition key exceed this threshold, the requests are throttled, generating a ProvisionedThroughputExceededException. Appending a random suffix distributes the write traffic across multiple partition keys and physical partitions. Concurrently, configuring the client SDK with exponential backoff and jitter prevents immediate client-side failures by spreading out retries over randomized intervals during traffic spikes.

Step-by-Step Solution

1
Analyze the error metrics and root cause.
Identify that the ProvisionedThroughputExceededException is occurring due to a hot partition (a single FarmID key receiving excessive write throughput) rather than the overall table-level capacity being exceeded.
DynamoDB partitions have a hard limit of 10001000 WCUs per second for writes. If this limit is exceeded on a single partition key, throttling occurs even if the table has spare capacity.
2
Select a strategy to distribute the write load.
Implement write sharding by appending a random integer suffix (e.g., from 11 to NN) to the FarmID partition key when writing data.
This spreads writes across NN distinct partition keys, distributing the workload across multiple physical partitions and bypassing the 10001000 WCU single-partition limit.
3
Configure the client retry behavior.
Modify the AWS SDK client settings to use exponential backoff and jitter.
Since the client currently fails immediately upon throttling, enabling backoff and jitter allows the client to retry requests after a randomized, increasing delay, which handles transient spikes gracefully.

Key Concept

DynamoDB partition write limitations and write sharding techniques
Estimated Time:2m 0s
Rate this question