A permit-search API misses its p99 latency SLO. CloudWatch and DynamoDB metrics show a few partition keys absorbing most traffic. Which performance improvement best addresses the bottleneck?
Select an answer to reveal the explanation.
Short Explanation
Hot keys are the one checkout lane with twenty carts while other lanes sit empty. Fix the key design or fan-out pattern, then put a cache in front of the celebrities. p99 calms down when the crowd stops crushing one partition.
Full Explanation
A permit-search API missing its p99 latency SLO while CloudWatch and DynamoDB metrics show a few partition keys absorbing most traffic is a classic hot-key bottleneck. Identifying hot keys or partitions, redesigning access patterns or key design as needed, and adding an appropriate cache such as DynamoDB Accelerator or application caching for hot reads addresses the performance root cause. That improvement works because aggregate table capacity cannot fix uneven key distribution—hot partitions throttle while cold ones idle. Switching the table to eventual consistency only and ignoring p99 as vanity fails conceptually: consistency mode does not remove hot-partition throttling, and p99 is the SLO. Deleting CloudWatch latency metrics so the SLO appears healthy fails by hiding citizen-visible pain. Forcing all traffic through a single Lambda in one AZ fails as a new bottleneck and availability anti-pattern. Exam caveat: caching helps hot reads but write-heavy hot keys may need key sharding or redesign; measure cache hit ratio and still fix underlying partition design. Operational check: use Contributor Insights or metrics to list top keys, prototype a cache for the hottest read path in nonprod, compare p99 to SLO under load, and schedule key-design remediation if writes remain concentrated.