Examkin

Question

Difficulty: MediumResolving DynamoDB Throttling and Key Distribution Issues

A customer loyalty rewards platform named "LoyaltyLink" processes member transactions and records reward point updates in an Amazon DynamoDB table. During a flash sale event, the application experiences a high volume of writes and starts throwing `ProvisionedThroughputExceededException` errors. The DynamoDB table partition key is `transaction_date` (formatted as YYYY-MM-DD), and the sort key is `member_id`. Although the total write throughput is well within the table's provisioned write capacity units (WCUs), the requests are heavily skewed towards the current date, causing throttling on a single partition. Which of the following approaches should a developer implement to resolve this throttling issue?

  1. Redesign the partition key schema by appending a random suffix (such as a number from 11 to NN) to the `transaction_date` partition key during writes, and update the application logic to query across all salted partitions.Answer
  2. B
    Increase the provisioned Write Capacity Units (WCUs) of the DynamoDB table to 50005000 to accommodate the temporary spike in write activity.
  3. C
    Integrate an Amazon SQS queue to buffer write requests and increase the SQS visibility timeout to 600600 seconds to prevent message processing duplicates.
  4. D
    Reconfigure the application to perform parallel Scan operations across 1010 segments to distribute the write workload evenly across the physical partitions.

Answer

Redesign the partition key schema by appending a random suffix (such as a number from 11 to NN) to the `transaction_date` partition key during writes, and update the application logic to query across all salted partitions.
The correct answer is to redesign the partition key schema by appending a random suffix to the `transaction_date` partition key during writes. Because DynamoDB partitions have a maximum write throughput limit of 10001000 WCUs, using a partition key with low cardinality (such as a single date for all transactions on that day) causes all writes to target a single partition, resulting in throttling. Adding a random suffix (salting) distributes the items across multiple partitions, overcoming the single-partition write limit.

Step-by-Step Solution

1
Identify the cause of the ProvisionedThroughputExceededException when total consumed capacity is within limits.
The issue is a hot partition key caused by using a highly skewed value (`transaction_date`), which routes all writes for a single day to the same physical partition, hitting the single-partition limit of 10001000 WCUs.
Understanding the physical limits of DynamoDB partitions is necessary to diagnose why scaling up overall capacity fails to resolve the issue.
2
Evaluate the correct design pattern for handling hot partition keys during writes.
Appending a random suffix (write sharding/salting) to the partition key distributes the write workload across multiple logical partitions.
Using a random suffix allows writes to be spread across multiple physical partitions, multiplying the maximum throughput for a single date.
3
Determine the changes required for read operations.
The application must be updated to query all potential salted partition keys (scatter-gather) to retrieve the full set of transactions for a given date.
Querying salted keys ensures that data can still be read reliably even though it is distributed across multiple partitions.

Key Concept

Handling DynamoDB hot partition keys using write sharding (salting) to distribute throughput across physical partitions.
Rate this question

Topics

Resolving DynamoDB Throttling and Key Distribution Issues