Examkin

Question

Difficulty: MediumResolving DynamoDB Throttling and Key Distribution Issues

An IoT telemetry platform named "VesselTrack" monitors maritime vessel operations. It records real-time sensor updates in an Amazon DynamoDB table. The table has a provisioned write capacity of 5,000 WCU. The partition key is `vessel_type` (e.g., "Cargo", "Tanker", "Passenger") and the sort key is `timestamp`. During peak operational hours, the application experiences frequent `ProvisionedThroughputExceededException` errors when writing cargo ship telemetry, even though the total write volume across the entire table is well below the table's total provisioned WCU limit.

Which TWO actions should the developer take to resolve these throttling issues and optimize the table's performance?

  1. Redesign the partition key schema by appending a calculated hash of the vessel ID to the vessel type (e.g., Cargo#12a3) to distribute writes more evenly across partitions.Answer
  2. Configure the application's AWS SDK client to implement exponential backoff with jitter for all write requests.Answer
  3. C
    Increase the provisioned write capacity of the table to 10,000 WCU to accommodate the write throughput for Cargo vessels.
  4. D
    Adjust the visibility timeout of the source Amazon SQS queue to be shorter than the DynamoDB write request timeout to prevent message processing duplicates.
  5. E
    Perform a DynamoDB Scan operation with a filter expression on vessel_type to group writing requests into bulk operations.

Answer

Redesign the partition key schema by appending a calculated hash of the vessel ID to the vessel type (e.g., Cargo#12a3) to distribute writes more evenly across partitions, and configure the application's AWS SDK client to implement exponential backoff with jitter for all write requests.
The ProvisionedThroughputExceededException is caused by a hot partition key ('Cargo' representing the majority of the writes), which overwhelms a single partition. Redesigning the partition key by adding a hash or suffix distributes the data across more partition keys. Additionally, configuring the AWS SDK with exponential backoff and jitter ensures that temporary retry spikes are handled gracefully.

Step-by-Step Solution

1
Analyze the table key schema and distribution of values.
Identify that the partition key 'vessel_type' has very low cardinality and 'Cargo' accounts for the vast majority of operations, leading to a hot partition.
DynamoDB tables partition data based on the partition key. Low cardinality partition keys with high traffic skew lead to uneven partition loading.
2
Apply write partition key sharding (salting).
Append a calculated hash of the vessel ID to the vessel type, which increases partition key cardinality and spreads writes across multiple physical partitions.
This resolves the structural hot partition issue by ensuring that different cargo ships write to different partition keys.
3
Implement exponential backoff and jitter in the application's SDK client.
The client handles transient throttling gracefully and avoids retry storms.
Randomized retry delays allow the table partitions to catch up and handle transient spikes without failing the overall request.

Key Concept

Resolving hot partition keys via key salting and handling throttling with SDK exponential backoff with jitter.
Estimated Time:2m 0s
Rate this question

Topics

Resolving DynamoDB Throttling and Key Distribution Issues