Question

Difficulty: HardResolving DynamoDB Throttling and Key Distribution Issues

A ticket booking application named TicketSwift records concert reservations in an Amazon DynamoDB table. The table uses ConcertID as the partition key and BookingTimestamp as the sort key. During major ticket releases, the application experiences a surge in ProvisionedThroughputExceededException errors, even though the total read and write capacity units (RCUs and WCUs) are auto-scaled and remain well below the table-level limits. An analysis shows that millions of requests are targeting a single popular concert within a few minutes. Which combination of actions will resolve this throttling issue and optimize key distribution? (Select TWO.)

  1. Redesign the partition key schema by appending a random numeric suffix to the ConcertID during high-volume booking events.Answer
  2. Configure the application SDK client to implement exponential backoff and jitter for retrying requests.Answer
  3. C
    Modify the application's queries to use a Scan operation with a FilterExpression to retrieve booking records.
  4. D
    Increase the visibility timeout of the incoming SQS queue to allow consumers more time to write records.
  5. E
    Increase the table's overall provisioned write capacity units (WCUs) to distribute write workloads evenly.

Answer

Redesigning the partition key schema by appending a random numeric suffix to the ConcertID and configuring the SDK to use exponential backoff and jitter.
Redesigning the partition key by appending a random numeric suffix (write sharding) distributes writes across multiple partitions, preventing a hot key issue. Implementing exponential backoff and jitter in the SDK handles transient throttling errors gracefully without overloading the database.

Step-by-Step Solution

1
Analyze the table schema and partition key design.
Identify that the ConcertID partition key results in a hot partition during popular ticket sales, because all writes for a concert hit the same physical partition.
DynamoDB partition capacity is limited, and high throughput on a single key leads to throttling despite table-level scaling.
2
Introduce sharding to the partition key.
Append a random numeric suffix (e.g., ConcertID_1, ConcertID_2) to distribute the write requests across multiple physical partitions.
This spreads the write load, increasing the aggregate throughput support for the concert writes.
3
Configure client-side error handling.
Implement exponential backoff and jitter in the application SDK for handling ProvisionedThroughputExceededException.
This prevents the client from overwhelming the database during transient spikes and ensures successful retries.

Key Concept

DynamoDB Partition Key Sharding and SDK Retries
Estimated Time:2m 0s
Rate this question