Design a DynamoDB single-table schema and avoid hot partition problems under high throughput

Verified steps

1. Identify all access patterns before designing the table; DynamoDB requires you to model around queries, not around entities — map each access pattern to a primary key (PK) and sort key (SK) combination, using prefixes like USER#<id> or ORDER#<id> to namespace item types
2. Use sparse Global Secondary Indexes (GSIs) for additional access patterns: only project the attributes you query, and only write the GSI keys on items that actually need that index to keep GSI size and cost minimal
3. Distribute writes across many partition key values — avoid keys like a static status code, date-only strings, or sequential IDs that funnel traffic to a small number of partitions; add a random suffix or shard number to high-cardinality hot keys
4. For known high-traffic partitions (e.g., a celebrity user), use write sharding: append a random integer (0–N) to the PK at write time and read from all N shards with parallel queries or a scatter-gather pattern
5. Enable DynamoDB auto-scaling or use on-demand capacity mode for unpredictable workloads; set separate read and write capacity targets and watch the ConsumedWriteCapacityUnits and ThrottledRequests CloudWatch metrics
6. Use condition expressions (ConditionExpression) and transactional writes (TransactWriteItems, max 100 items) to enforce consistency without application-level locking