SAA-C03 Design High-Performing Architectures Practice Question

Your mobile app writes events to a single DynamoDB table with partition key = customerId and sort key = eventTime. During a promotional campaign, one tenant ("ACME") generates far more traffic than others. CloudWatch shows sustained throttling (ProvisionedThroughputExceeded) and elevated p99 latency only for that tenant. The workload pattern cannot be changed to a completely different schema, but you can change how items are partitioned. Which design change is most likely to reduce the hot-partition throttling while keeping efficient reads for ACME?

⚠ Common exam trap

Many exam-takers assume increasing capacity or switching to on-demand alone solves hot partitions, but they overlook DynamoDB's fixed per-partition throughput limits that require key design changes to distribute load.

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

✓

Change the partition key to a salted key such as customerId + shard number, and include the eventTime ordering using the sort key.

Salting the partition key by appending a shard number (e.g., customerId + random digit) distributes ACME's writes across multiple partitions, eliminating the hot partition. The sort key still preserves eventTime ordering, so queries for a specific customer can be parallelized across shards and merged client-side or via a composite sort key pattern, maintaining efficient reads.

Answer analysis

Option-by-option breakdown

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

✗
Use the same partition key (customerId), but increase the table’s provisioned capacity for that tenant.
Why it's wrong here
Increasing provisioned capacity can raise the overall throughput ceiling, but DynamoDB throttling for a hot partition is driven by per-partition limits (and uneven item/key distribution), not just by the table’s total capacity. If nearly all ACME writes still target the same partition (same customerId value), that single partition can remain the bottleneck, so throttling and p99 latency can persist during spikes.
✓
Change the partition key to a salted key such as customerId + shard number, and include the eventTime ordering using the sort key.
Why this is correct
Hot-partition throttling happens when a single logical partition (one partition key value) receives more requests than it can serve. By salting the partition key (for example, customerId#shardId), ACME’s writes are spread across multiple physical partitions, reducing request rate per partition and lowering throttling. Efficient reads for ACME can be preserved by querying only the shard partitions that belong to ACME (for example, using a small, deterministic set of shardIds and issuing parallel queries per shard, then merging results). This avoids scanning the whole table and keeps access patterns predictable while improving tail latency.
✗
Switch to on-demand capacity mode and keep the partition key unchanged.
Why it's wrong here
On-demand capacity automatically scales the table’s overall capacity, but it does not remove per-partition request limits. If all ACME traffic still targets one partition key value, that partition can still become hot and throttle, so p99 latency and ProvisionedThroughputExceeded events can continue during spikes.
✗
Enable Global Tables so that reads are served from a nearby replica for ACME.
Why it's wrong here
Global Tables can reduce network latency and improve availability across regions, but they do not address hot partitions within a region. If ACME’s writes concentrate on a single partition key value, the corresponding partition in each replica can still be the throttling bottleneck for that tenant.

Go deeper

SAA-C03 Design High-Performing Architectures Practice Question

Why each option matters

Option-by-option breakdown

Related to this question