SAA-C03 Design High-Performing Architectures Practice Question

A retail analytics table stores events in Amazon DynamoDB with partition key tenantId and sort key eventTime. During a promotion, one tenant generates most writes and repeatedly polls the same latest-status items, causing throttling on a single partition key and high latency on reads. The business can tolerate read results that are a few seconds stale. Which two changes will most effectively reduce throttling and latency? Select two.

⚠ Common exam trap

Many candidates assume DAX alone can fix both read and write throttling, but DAX only caches reads and does not address the write-side partition bottleneck that causes throttling in the first place.

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

✓

Introduce write sharding by adding a bounded random suffix to the hot tenant partition key and fan out reads across the shards.

Write sharding distributes the hot tenant's writes across multiple partitions by appending a bounded random suffix to the partition key, preventing a single partition from throttling. Reads then fan out across all shards and aggregate results, which is acceptable since the business tolerates a few seconds of staleness. This directly addresses the single-partition bottleneck without changing the overall data model.

Answer analysis

Option-by-option breakdown

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

✓
Introduce write sharding by adding a bounded random suffix to the hot tenant partition key and fan out reads across the shards.
Why this is correct
Sharding spreads the hot tenant’s traffic across multiple partitions so DynamoDB is no longer forced to serve all writes through one physical partition. Querying across the shard set restores access to the tenant’s data while reducing throttling. This is the standard fix when a single partition key becomes a hot spot.
✓
Add DynamoDB Accelerator (DAX) in front of the table for the repeated status reads.
Why this is correct
DAX can serve repeated eventually consistent reads from an in-memory cache with microsecond latency. Because the business accepts a few seconds of staleness, DAX is a strong fit for the repeated latest-status access pattern. It reduces read pressure on the table and improves response times for hot read paths.
✗
Keep the same key design and increase only the table’s provisioned RCUs and WCUs.
Why it's wrong here
More capacity can help only if the workload is broadly distributed. A single hot partition key can still bottleneck even when table capacity is raised. This option does not change the skewed access pattern that is causing throttling on one partition.
✗
Replace the table reads with a Scan operation to distribute the load across all partitions.
Why it's wrong here
A Scan reads many items and is far more expensive and slower than a targeted Query. It would increase latency and consume more capacity, not reduce it. Scans are not a solution for a hot key or for low-latency repeated reads.
✗
Move the table to another Availability Zone so the hot tenant uses a different storage node.
Why it's wrong here
DynamoDB is a regional service and its partitioning behavior is not solved by picking a different AZ. The issue is logical data skew, not a single-AZ placement problem. Moving the table would not change the hot partition key pattern.

Go deeper

SAA-C03 Design High-Performing Architectures Practice Question

Why each option matters

Option-by-option breakdown

Related to this question