A city stores every parking ticket under the DynamoDB partition key CITY#ALL, causing a hot partition during ticket season. How should the key design change?
Select an answer to reveal the explanation.
Short Explanation
CITY#ALL is one overstuffed filing cabinet—everyone slams the same drawer in ticket season. Spread keys across many ticket IDs (high cardinality) so DynamoDB can use many partitions. A key named HOT just brags about the problem.
Full Explanation
A city that stores every parking ticket under the DynamoDB partition key CITY#ALL creates a hot partition during ticket season—the key design should use high-cardinality partition keys (for example ticket ID or a well-distributed composite) so writes and reads spread across partitions. Single-value partition keys funnel all traffic onto one partition until throttling appears despite unused table capacity. Distributing by ticket ID, hashed beat ID plus time bucket, or similar high-cardinality designs restores scalable write throughput for enforcement peaks.
Keeping CITY#ALL and adding a GSI that also uses CITY#ALL as its partition key simply creates another hot partition. Exporting tickets to a single EC2 local JSON file abandons DynamoDB’s managed scaling model. Changing the partition key to another constant such as TICKETS repeats the same anti-pattern with different spelling.
Exam caveat: sort keys still matter for query patterns (for example ticket ID as partition and event time as sort). Avoid hot keys from popular status values as partition keys; use sparse GSIs or carefully designed composites. Hot-partition fixes often require a migration plan for existing items.
Operational check: redesign the primary key with high cardinality; load-test ticket-season write rates; watch for throttling per partition metrics; migrate old CITY#ALL items deliberately; and document access patterns for collection apps and cashier lookups.