A gaming company uses Amazon DynamoDB with global tables across two regions. They notice increased write latency and throttling during peak hours. The access pattern is mostly writes to a small set of hot partitions. Which design change would best address this?
Write sharding distributes writes evenly across partitions.
Why this answer
The correct answer is A because the issue is hot partitions caused by a small set of partition keys receiving the majority of writes. By implementing write sharding with a random suffix on the partition key, you distribute writes across multiple partitions, reducing throttling and write latency. This directly addresses the root cause of uneven access patterns, unlike the other options that either cache reads, adjust capacity mode, or scale capacity without solving the partition-level bottleneck.
Exam trap
The trap here is that candidates often confuse throughput scaling (options C and D) with partition-level distribution, failing to recognize that hot partitions require a key design change, not just capacity adjustments.
How to eliminate wrong answers
Option B is wrong because DynamoDB Accelerator (DAX) is an in-memory cache that primarily improves read performance, not write latency or throttling on hot partitions. Option C is wrong because switching to on-demand capacity mode handles traffic spikes but does not resolve the underlying hot partition issue; throttling can still occur at the partition level if a single partition exceeds its throughput limit. Option D is wrong because increasing write capacity with auto scaling only raises the table-level throughput, but if writes are concentrated on a few partitions, those partitions will still hit their individual limits and cause throttling.