A food-delivery company has an application that uses an Amazon DynamoDB table for customer orders.

Amazon DynamoDB throttling during peak periods is commonly caused by hot partitions. In this scenario, using order_date as the partition key results in a large number of writes targeting the same partition during peak ordering times. Even in on-demand mode, DynamoDB enforces per-partition limits, which leads to throttling when traffic is unevenly distributed.

AWS best practices emphasize designing partition keys that provide high cardinality and uniform access patterns. Using customerId as the partition key distributes write traffic across many partitions because customer IDs naturally vary and scale with the number of users.

Switching to provisioned capacity (Option B) does not solve the root cause and can still result in throttling due to uneven access patterns. Sequential partition keys (Option A) worsen the hot partition problem. Migrating to Aurora (Option C) is unnecessary and does not address DynamoDB design issues.

AWS documentation clearly states that access pattern design is critical, and changing the partition key to better distribute workload is the correct solution. Therefore, using customerId as the partition key resolves throttling and aligns with DynamoDB best practices.