Examkin

Question

Difficulty: Very hardResolving DynamoDB Throttling and Key Distribution Issues

An IoT application managed by AeroFleet Logistics tracks real-time location data for thousands of delivery vehicles. The application writes updates to an Amazon DynamoDB table. The table's partition key is `vehicle_status` (which only contains values such as `ACTIVE`, `INACTIVE`, or `MAINTENANCE`), and the sort key is a timestamp. During peak hours, the application frequently receives `ProvisionedThroughputExceededException` errors during writes. A review of CloudWatch metrics shows that the overall table-level consumed Write Capacity Units (WCUs) are far below the provisioned WCU limit, but writes are heavily skewed to a single partition key value. Which of the following combinations of actions should the developer take to resolve these throttling issues and make the application more resilient to transient write failures? (Select TWO options.)

  1. Redesign the partition key schema by appending a calculated or random suffix (e.g., 11 to NN) to the `vehicle_status` partition key to distribute write operations across multiple physical partitions.Answer
  2. Configure the application SDK client to implement exponential backoff with jitter for write requests to handle throttling during write spikes gracefully.Answer
  3. C
    Increase the visibility timeout of the upstream Amazon SQS queue that feeds the location updates to avoid duplicate writes during database throttling events.
  4. D
    Modify the application to perform parallel Scan operations with Segment parameters to quickly identify and remove inactive vehicle status records.
  5. E
    Hardcode the IAM access key and secret key directly into the application SDK initialization code to speed up authentication and reduce connection latency.

Answer

Redesign the partition key schema by appending a calculated or random suffix to the partition key, and configure the SDK client to implement exponential backoff with jitter.
The correct response involves redesigning the partition key schema by appending a calculated suffix (write-sharding) and modifying the client SDK retry configurations. Adding a suffix distributes writes across multiple partition keys, mitigating hot partition problems. Implementing exponential backoff with jitter ensures that retry attempts do not overwhelm the partition during traffic surges.

Step-by-Step Solution

1
Diagnose the root cause using CloudWatch metrics.
Confirmed that partition key cardinality is too low, causing skewed traffic to a single partition, exceeding the limit of 10001000 WCUs per partition.
To verify that the ProvisionedThroughputExceededException is due to hot partitions rather than overall table WCU exhaustion.
2
Introduce write sharding using synthetic suffixes.
Append a randomized or calculated suffix (e.g., 11 to NN) to the `vehicle_status` partition key, shifting the key structure from single values to distributed partitions.
To distribute write throughput evenly across multiple physical partitions and eliminate hot partition bottlenecks.
3
Implement exponential backoff and jitter in the application SDK.
Client retries are spaced out progressively and randomized rather than hitting the database simultaneously.
To gracefully manage temporary spikes in database load and avoid retry storms that worsen throttling.

Key Concept

Write sharding via synthetic key suffixes to distribute traffic across physical partitions, combined with client-side retry policies (exponential backoff with jitter) to build resilient database integrations.
Estimated Time:3m 0s
Rate this question

Topics

Resolving DynamoDB Throttling and Key Distribution Issues