A utility writes high-scale meter readings to DynamoDB. Hot partitions are causing throttling on a few keys. Which access-pattern design best improves performance?
Select an answer to reveal the explanation.
Short Explanation
DynamoDB partitions hate a traffic magnet on one key—like one toll booth for the whole city. Spread meter IDs (or a well-designed composite) so load fans out. One shared key, overwriting one item, or piling work onto a hot partition keeps the throttling.
Full Explanation
DynamoDB throughput is partitioned, so high-scale utility meter writes must spread across many partition keys rather than concentrating on a few hot keys. Choosing partition keys that diversify meter load—typically meter identifiers or well-designed composites—avoids hot partitions and throttling as AMI readings pour in. Even key distribution is the Task 3.3 access-pattern design that restores high-performing database writes for civic telemetry. Using a single partition key value such as METER for every reading fails because nearly all traffic lands on one partition, guaranteeing hot-key throttling under scale. Overwriting the same item key for all meters to keep the table tiny fails conceptually: it destroys per-meter history, serializes writes onto one item, and maximizes contention instead of spreading load. Disabling eventual consistency reads so every query hits one overloaded partition fails because consistency mode does not fix a bad key design and forcing more work onto a hot partition worsens throttling. Exam caveat: spreading keys is necessary but not always sufficient—watch for hot meters, time-series write patterns that need sharding suffixes, and GSIs that can create their own hot partitions. Operational check: review WriteThrottleEvents and partition-level metrics, redesign keys or add write sharding for hot meters, replay a peak AMI burst in a test table, and confirm throttles drop before promoting the access pattern.