An event ingestion service writes to a DynamoDB table where the partition key is tenantId and the sort key is eventTime. During a campaign, one tenant generates a disproportionate share of traffic, causing write throttling and increased latency for that tenant’s writes. You can change the data model and application queries, but you must still efficiently retrieve events for a tenant for the last 10 minutes. Which change best improves write throughput by reducing hot partitions?
This “write sharding” spreads a tenant’s traffic across multiple partition key values, which distributes the write load across multiple DynamoDB partitions (and thus multiple throughput slices). Reads for the last 10 minutes remain efficient because each shard still supports a sort-key range query on eventTime; the application merges results across shards.
Why this answer
It distributes writes for a hot tenant across multiple partitions by appending a random shard suffix to the tenantId partition key. This eliminates a single hot partition, allowing DynamoDB to scale write capacity horizontally. The application can then query all shards for the last 10 minutes and merge results, satisfying the retrieval requirement.
Exam trap
The trap here is that candidates assume adaptive capacity or caching (DAX) can solve write throttling, but neither addresses the root cause—a single partition exceeding its write capacity—which requires redistributing the partition key across multiple physical partitions.
How to eliminate wrong answers
Option A is wrong because DynamoDB adaptive capacity can only mitigate moderate hot spots by temporarily allocating extra capacity, but it cannot eliminate throttling when a single partition exceeds its 1,000 WCU or 3,000 RCU limit; sustained high traffic from one tenant will still cause throttling. Option C is wrong because changing the sort key to eventTimeBucket does nothing to distribute writes across partitions—the partition key remains tenantId, so all writes for that tenant still target the same partition, leaving the hot partition problem unsolved. Option D is wrong because DAX is a read-through cache and does not handle write operations; throttled writes are not served from cache, and DAX cannot increase write throughput or reduce hot partition contention.