Examkin

Soru

Zorluk: OrtaResolving DynamoDB Throttling and Key Distribution Issues

A document collaboration platform named DocuCollab tracks real-time document editing events and writes them to an Amazon DynamoDB table. The table is configured with provisioned write capacity and uses the DocumentId as the partition key. During peak hours, a small number of extremely popular shared documents experience heavy, concurrent editing activity. This results in ProvisionedThroughputExceededException errors and writes are dropped, even though the total consumed write capacity is well below the table's provisioned limit.

Which combination of actions will resolve this issue? (Select TWO.)

  1. Append a random numeric suffix to the partition key value before writing the items to distribute the write load.Cevap
  2. Configure the application SDK client to implement exponential backoff with jitter for retrying failed requests.Cevap
  3. C
    Increase the provisioned Write Capacity Units (WCUs) on the DynamoDB table to distribute the capacity across all partition keys.
  4. D
    Increase the visibility timeout of the Amazon SQS queue that buffers the writes to allow the consumer more time to retry without message duplication.
  5. E
    Initialize the DynamoDB SDK client using static credentials with administrative privileges to bypass partition write limits.

Cevap

To resolve the throttling issues, the developer should append a random numeric suffix to the partition key value before writing the items, and configure the application SDK client to implement exponential backoff with jitter for retrying failed requests.
The correct actions are appending a random numeric suffix to the partition key (sharding) and configuring the SDK to use exponential backoff with jitter. Appending a random suffix distributes the concurrent writes for a single popular document across multiple physical partitions, which prevents exceeding the 1,000 WCU physical partition limit. Implementing exponential backoff with jitter ensures that when throttling does occur, the application retries the requests at progressively longer, randomized intervals, preventing retry storms and allowing the writes to succeed without being dropped.

Adım Adım Çözüm

1
Analyze the DynamoDB ProvisionedThroughputExceededException and partition key design to identify if the workload is unevenly distributed.
Discovered that a few popular documents (hot partition keys) are exceeding the single physical partition throughput limit of 1,000 WCUs, even though the total table WCU consumption is low.
This step is necessary to pinpoint that the problem is a hot partition issue rather than a table-wide capacity limitation.
2
Redesign the partition key strategy by appending a random numeric suffix (e.g., a hash or random number from 1 to N) to the DocumentId before writing.
Writes for a single popular document are distributed across N different partition keys, spreading the throughput load across multiple physical partitions.
This step is required to scale the throughput of a single logical key beyond the 1,000 WCU physical partition limit.
3
Configure the application SDK client to implement exponential backoff with randomized jitter for request retries.
Throttled requests are retried with spacing in time, preventing collision patterns (retry storms) and allowing temporary spikes to resolve successfully.
This step is necessary to ensure that the application handles transient throttling gracefully without immediately dropping write requests.

Anahtar Kavram

Resolving DynamoDB throttling issues by redesigning partition keys (sharding) and configuring SDK retry policies with backoff and jitter.
Tahmini Süre:2m 0s
Bu soruyu puanla

Konular

Resolving DynamoDB Throttling and Key Distribution Issues