A DynamoDB table storing IoT sensor readings uses the sensor's model number as the partition key, and there are only six distinct model numbers across millions of devices. Under heavy write load, requests to the table are frequently throttled even though the table's overall provisioned throughput is far from the account limit. What is the most likely cause?
- The table is missing a global secondary index
- The low-cardinality partition key concentrates traffic onto a small number of partitions, creating hot partitions
- DynamoDB Streams is enabled and consuming write capacity
- The items exceed the 400 KB item size limit
Why B? And why not the others?
Correct answer: B. The low-cardinality partition key concentrates traffic onto a small number of partitions, creating hot partitions
DynamoDB spreads a table's data and throughput across partitions based on the partition key's hash value, so a partition key with only a handful of distinct values funnels the overwhelming majority of read and write activity onto just a few physical partitions no matter how much total throughput is provisioned for the table, producing throttling on those hot partitions well before the table-wide capacity is exhausted; the fix is to choose a higher-cardinality key, such as a device ID, or add a randomizing suffix. The option about a missing GSI is wrong because a secondary index changes query flexibility, not the base table's write distribution, and would not by itself cause primary-table write throttling. The option about DynamoDB Streams is wrong because enabling Streams only captures a change log asynchronously and does not consume the table's provisioned read or write capacity. The option about the item size limit is wrong because exceeding that limit produces an explicit validation error on the offending write, not intermittent throttling across the table.
Source: AWS DynamoDB documentation: partition key design and hot partitions