Partitions are usually throttled when they are accessed by your downstream applications much more frequently than other partitions (that is, a "hot" partition), or when workloads rely on short periods of time with high usage (a "burst" of read or write activity).

To avoid hot partitions and throttling, you must optimize your table and partition structure by following the best-practice strategies at

Consider one or more of the following solutions:

• Increase the amount of read or write capacity for your table to anticipate short-term spikes or bursts in read or write operations. If you decide later you don't need the additional capacity, decrease it.
  Note:
  Before deciding on how much to increase read or write capacity, consider the best practices at Designing Partition Keys to Distribute Your Workload Evenly.
• This technique uses progressively longer waits between retries for consecutive error responses to help improve an application's reliability. If you're using an AWS SDK, this logic is built‑in; otherwise, consider implementing it manually.
• Distribute your read operations and write operations as evenly across your table as possible. A "hot" partition can degrade the overall performance of your table.
• DAX is a DynamoDB-compatible caching service that offers fast in‑memory performance for your application. If your workload is mostly read access to static data, query results can often be served more quickly from a well‑designed cache than from a database.

Adaptive capacity activates within 5‑30 minutes to help mitigate short‑term workload imbalance issues. However, each partition will still be subject to the hard limit of 1000 write capacity units and 3000 read capacity units, so adaptive capacity can't solve larger issues with your table or partition design.