Question

Difficulty: MediumResolving DynamoDB Throttling and Key Distribution Issues

An agricultural IoT application named 'CropSense' collects hourly soil moisture data from thousands of sensors in a region. The sensor data is written to an Amazon DynamoDB table. The table is configured with a partition key of `SensorType` (which has only three distinct values: 'Moisture', 'Temperature', and 'Acidity') and a sort key of `Timestamp`. During peak reporting windows, the application experiences a high volume of `ProvisionedThroughputExceededException` errors, even though the total read/write capacity units consumed are well below the table's allocated capacity. Which of the following actions is the most appropriate way to resolve this throttling issue?

  1. A
    Increase the table's provisioned write capacity units (WCUs) to scale up the overall write throughput limit of the table.
  2. B
    Increase the visibility timeout of the upstream Amazon SQS queue to allow more time for the application to process each write request.
  3. Redesign the partition key schema by appending a random or calculated numeric suffix to the partition key (e.g., Moisture_N, where NN is a random integer between 11 and 1010) to distribute write operations across multiple partition keys.Answer
  4. D
    Hardcode the AWS access keys directly within the SDK client initialization configuration to eliminate credential provider chain lookup latency.

Answer

Redesign the partition key schema by appending a random or calculated numeric suffix to the partition key (e.g., Moisture_N, where NN is a random integer between 11 and 1010) to distribute write operations across multiple partition keys.
The throttling is caused by a hot partition key because the partition key (SensorType) has low cardinality (only three values). This concentrates writes on a small number of physical partitions, exceeding the partition-level throughput limits. Appending a random or calculated numeric suffix to the partition key distributes the write operations across a larger number of logical keys, solving the partition-level bottleneck.

Step-by-Step Solution

1
Analyze the DynamoDB table design and identify the partition key cardinality.
The partition key has only three distinct values: 'Moisture', 'Temperature', and 'Acidity'.
This low cardinality causes all writes to be directed to only three logical partitions, creating a hot partition issue.
2
Differentiate between table-level capacity limits and partition-level throughput limits.
Throttling occurs because the write volume to one of the three partitions exceeds the partition limit (e.g., 10001000 WCUs per second), even if the overall table capacity is not exceeded.
Scaling up total capacity (WCUs) will not help if individual partition limits are exceeded.
3
Implement write sharding by adding a suffix to the partition key.
Using a schema like `SensorType_N` distributes the data across multiple partitions.
This evenly distributes the write throughput workload, resolving the ProvisionedThroughputExceededException errors.

Key Concept

Write sharding (appending a suffix to partition keys) to distribute highly skewed workloads in Amazon DynamoDB.
Rate this question