An accounting application named LedgerSync records daily business transactions into an Ama… — AWS Certified Developer - Associate

An accounting application named LedgerSync records daily business transactions into an Amazon DynamoDB table. The table is configured with a partition key of `TransactionDate` (formatted as `YYYY-MM-DD`) and a sort key of `TransactionId`. The table is provisioned with $1,000$ Write Capacity Units (WCUs). During end-of-month reconciliation, batch processing writes hundreds of thousands of transactions for the same calendar date within a 10-minute window. Even though the total write request rate is well below the table's overall provisioned $1,000$ WCUs, the application repeatedly encounters `ProvisionedThroughputExceededException` errors. Which of the following approaches is the most effective way to resolve this throughput issue while maintaining cost efficiency?

Redesign the partition key schema by appending a calculated or random suffix to the date, distributing the write load across multiple logical partitions, and adjust queries to target those partitioned keys.Cevap
B
Increase the overall Provisioned Write Capacity Units (WCUs) of the DynamoDB table to $10,000$ during the reconciliation window to scale partition capacity limits.
C
Modify the application logic to use DynamoDB Scan operations instead of Query operations to retrieve transaction records in parallel during reconciliation.
D
Increase the visibility timeout of the Amazon SQS queue that buffers the incoming transaction writes to allow consumers more time to execute writes to the DynamoDB table.

Cevap

Redesign the partition key schema by appending a calculated or random suffix to the date, distributing the write load across multiple logical partitions, and adjust queries to target those partitioned keys.

The correct answer is correct because DynamoDB enforces a strict limit of

1,000

Write Capacity Units (WCUs) per partition. When all incoming writes target a single partition key value (such as the same `TransactionDate`), they are directed to the same partition, exceeding its throughput limit and triggering `ProvisionedThroughputExceededException`. Appending a synthetic suffix (such as a random or calculated number) to the partition key distributes the write load across multiple logical keys and physical partitions, raising the effective throughput limit for that date while keeping the table cost-effective.

Adım Adım Çözüm

Analyze the workload and table schema.

Identify that the partition key is `TransactionDate`. During reconciliation, all writes for a specific date target a single partition key value (e.g., '2026-06-30').

This concentrates all writes into a single logical partition key, creating a hot partition key.

Evaluate DynamoDB partition limits against the workload requirements.

Realize that a single partition key has a maximum throughput limitation of

1,000

WCUs (or

1,000

writes/sec). Total table capacity does not bypass this individual key limit.

Knowing this limit explains why provisioned throughput exceeded errors occur despite having sufficient overall capacity.

Apply a sharding strategy (adding a synthetic suffix) to partition keys.

Append a suffix (e.g., a random number between

1

and

10

) to `TransactionDate` before saving, yielding keys like `2026-06-30_1` to `2026-06-30_10`.

This distributes the writes across multiple logical partitions, allowing up to

10 \times 1,000 = 10,000

WCUs for that day's data.

Anahtar Kavram

Mitigating DynamoDB hot partition key bottlenecks via write sharding (adding a synthetic suffix).

Tahmini Süre:2m 0s

Soru

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Konular