Resolving DynamoDB Hot Partition Throttling Using DAX

A company uses Amazon DynamoDB as its primary database. The operations team is seeing increased read latency during peak hours. The table has a provisioned read capacity of 1000 RCU, but CloudWatch metrics show that consumed read capacity frequently reaches 1000 RCU. The application uses eventually consistent reads. What is the MOST cost-effective way to reduce read latency?

⚠ Common exam trap

SAP-C02 often tests whether candidates reflexively choose 'increase capacity' for latency problems — the trap is recognizing that caching (DAX) is more cost-effective than over-provisioning when reads are repetitive and eventually consistent.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Enable DynamoDB Accelerator (DAX) to cache frequently read items.

DAX is an in-memory cache purpose-built for DynamoDB that sits in front of the table and serves eventually consistent reads with microsecond latency, offloading read traffic from the table. Since the application already uses eventually consistent reads and the table is at its RCU ceiling during peaks, caching frequently read items in DAX reduces consumed RCU and latency without over-provisioning capacity. It is the most cost-effective fix because it addresses the root cause (repeated reads of hot items) rather than adding raw capacity.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Switch to strongly consistent reads to improve consistency.
Why it's wrong here
Strongly consistent reads consume twice the RCU of eventually consistent reads, so switching doubles capacity consumption on an already saturated table and worsens throttling. It is tempting because consistency sounds like an improvement, and strongly consistent reads would be correct where the application cannot tolerate stale data.
✓
Enable DynamoDB Accelerator (DAX) to cache frequently read items.
Why this is correct
DAX sits in front of DynamoDB and serves eventually consistent reads from an in-memory cache, absorbing repeated item reads so they bypass the table entirely. This reduces latency during peaks without raising provisioned read capacity, keeping cost low.
✗
Create a global secondary index (GSI) on the table to offload reads.
Why it's wrong here
A GSI duplicates the table's data and consumes its own provisioned capacity, adding cost and write amplification without relieving the base table's exhausted 1000 RCU. It is tempting because GSIs do serve different query patterns, and a GSI would be correct when reads need an alternative partition or sort key.
✗
Increase the provisioned read capacity to 2000 RCU.
Why it's wrong here
Raising provisioned capacity to 2000 RCU doubles the hourly cost of the table while leaving the underlying hot-partition or access-pattern cause of the latency unaddressed. It is tempting because throttling from exhausted capacity looks like the obvious culprit, and scaling RCU would be correct for genuinely uniform read growth across partitions.
✗
Use Amazon ElastiCache for Memcached as a read cache.
Why it's wrong here
While ElastiCache for Memcached can reduce read load by caching frequently accessed data, it fails here because the bottleneck is provisioned RCU saturation, not a lack of caching. The correct solution must increase read capacity or use DAX, which integrates directly with DynamoDB’s API and handles cache invalidation automatically. Memcached is tempting because it offloads database reads in general, but it would require custom application logic to manage cache misses and staleness, making it less direct for DynamoDB’s eventual consistency model.

Go deeper

Resolving DynamoDB Hot Partition Throttling Using DAX

Why each option matters

Option-by-option breakdown

Related to this question