A logistics table in DynamoDB throttles one popular tracking key while the table's consumed capacity stays well under its provisioned ceiling. Other keys on the table are fine. What should change?
Select an answer to reveal the explanation.
Short Explanation
The whole highway is empty and one toll booth is backed up for miles. You are throttling a single popular key, so extra table capacity does not give that key a second booth. Spread the item across more than one partition, because a second Region still lands that same key on one partition.
Full Explanation
DynamoDB distributes items by partition key. A single key, no matter how hot, is stored on one partition, and that partition can throttle while the table's overall consumed capacity looks comfortable. Raising the table's provisioned capacity adds throughput the hot key cannot fully use, because the key does not spread across the new capacity. The durable fix is a key design that splits the hot item, for example by writing shards of that tracking id, so the workload uses more than one partition. A global table copies the same item to another Region. Each Region still partitions by the same key, so the hot key remains hot. On-demand on the quiet keys does not change the partition of the one key that is throttling, and a second table for that key only helps if the key itself is split. Caveat: sharding the key means reads must know how to assemble the shards, so the application change ships with the data change. Operational check: after the new keys are in use, confirm the throttle metric for the old key falls and that no single new key consumes the partition on its own.