How Do You Design a Good Partition Key in DynamoDB?
Learn how to design a good DynamoDB partition key, avoid hot partitions, and use write sharding for scalable NoSQL tables.
Expected Interview Answer
A good DynamoDB partition key spreads items as evenly as possible across the table's underlying partitions by having high cardinality and uniform access frequency, so no single partition absorbs a disproportionate share of read or write traffic and gets throttled.
DynamoDB hashes the partition key to decide which physical partition stores an item, and each partition has fixed throughput capacity, so a key with low cardinality (like a status field with three values) or one where a few values are accessed far more than others (like a single trending product ID) creates a 'hot partition' that throttles requests even if the table's overall provisioned capacity is high. Good designs use high-cardinality identifiers like a user ID or, when access naturally concentrates on one entity, add a random or calculated suffix to spread that entity's items across several synthetic partition keys. Combined with a well-chosen sort key, this lets a single table serve multiple access patterns efficiently, which is central to DynamoDB's single-table design philosophy.
- Even key distribution avoids hot-partition throttling
- High-cardinality keys let DynamoDB scale throughput linearly with added partitions
- Sort keys combined with partition keys enable rich query patterns from one table
- Techniques like write sharding fix hot keys that cannot be redesigned away
AI Mentor Explanation
Think of a stadium with many entry gates where each gate is staffed to handle an even share of the crowd. If every ticket said 'enter through Gate 1' regardless of the seat, Gate 1 would be overwhelmed while the other gates sat empty. A DynamoDB partition key works the same way: it must route items evenly across the table's underlying partitions, using something high-cardinality like a booking ID rather than a low-cardinality field like match-day, or one gate absorbs all the traffic and throttles.
Step-by-Step Explanation
Step 1
Identify access patterns first
List every query the application will run before choosing a partition key, per DynamoDB's query-first design.
Step 2
Choose a high-cardinality key
Prefer identifiers like user ID or order ID over low-cardinality fields like status or category.
Step 3
Check for access skew
Even a high-cardinality key can be hot if a few values (e.g. a viral item) receive most of the traffic.
Step 4
Apply write sharding if needed
Append a random or calculated suffix to a hot key's value to spread its items across synthetic partitions.
What Interviewer Expects
- Understanding that the partition key determines physical data distribution
- Ability to identify low-cardinality or skewed-access keys as hot-partition risks
- Knowledge of the write-sharding technique for unavoidably hot keys
- Awareness of DynamoDB's single-table, query-first design philosophy
Common Mistakes
- Choosing a low-cardinality partition key like status or boolean flag
- Ignoring access-frequency skew even when cardinality looks high on paper
- Not considering a composite or sharded key for a naturally hot entity
- Designing the table schema before listing the application's access patterns
Best Answer (HR Friendly)
“In DynamoDB, the partition key decides which physical partition stores an item, so I choose a high-cardinality key like a user or order ID rather than something with only a few values, which keeps traffic spread evenly and avoids one partition getting throttled. If one key value is naturally much hotter than others, I add a random suffix to spread its writes across several partitions.”
Code Example
// Naive design: all writes for a viral product hit one partition
// PK = "PRODUCT#viral-item-123" -- hot partition risk
// Sharded design: spread writes across N synthetic partitions
function shardedKey(productId, shardCount = 10) {
const shard = Math.floor(Math.random() * shardCount);
return `PRODUCT#${productId}#SHARD#${shard}`;
}
await dynamoDb.putItem({
TableName: 'Orders',
Item: {
PK: { S: shardedKey('viral-item-123') },
SK: { S: `ORDER#${orderId}` },
quantity: { N: '1' }
}
});
// Reads aggregate results across all shard values
// for a full count of orders on that product.Follow-up Questions
- What is the difference between a partition key and a sort key in DynamoDB?
- How does DynamoDB's single-table design use sort key prefixes to model multiple entity types?
- What are global secondary indexes and how do they support additional access patterns?
- How does DynamoDB adaptive capacity help mitigate moderate hot-partition issues automatically?
MCQ Practice
1. What is the main risk of choosing a low-cardinality DynamoDB partition key?
A low-cardinality key concentrates items (and traffic) onto few partitions, which can exceed that partition's throughput and throttle requests.
2. What technique helps distribute writes for an unavoidably hot partition key value?
Write sharding appends a random or calculated suffix to the key, spreading one logical entity's items across multiple physical partitions.
3. What determines which physical partition a DynamoDB item is stored on?
DynamoDB hashes the partition key value to determine the physical partition responsible for storing that item.
Flash Cards
What makes a good DynamoDB partition key? — High cardinality and uniform access frequency, so items and traffic spread evenly across partitions.
What is a hot partition? — A partition receiving disproportionate traffic, causing throttling even with adequate overall table capacity.
What is write sharding? — Appending a random or calculated suffix to a hot key to spread its items across multiple synthetic partitions.
What should drive DynamoDB schema design? — The application's access patterns, identified before the table is designed.