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.)
- Redesign the partition key schema by appending a random numeric suffix to the ConcertID during high-volume booking events.Cevap
- Configure the application SDK client to implement exponential backoff and jitter for retrying requests.Cevap
- CModify the application's queries to use a Scan operation with a FilterExpression to retrieve booking records.
- DIncrease the visibility timeout of the incoming SQS queue to allow consumers more time to write records.
- EIncrease the table's overall provisioned write capacity units (WCUs) to distribute write workloads evenly.
Cevap
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.
Adım Adım Çözüm
Anahtar Kavram
DynamoDB Partition Key Sharding and SDK Retries
Tahmini Süre:2m 0s