What is a hot partition in DynamoDB and how do you avoid it?
Understand what a DynamoDB hot partition is, why it throttles traffic, and how high-cardinality keys and write sharding prevent it, with code and Q&A.
Expected Interview Answer
A hot partition in DynamoDB is a single physical partition that receives a disproportionate share of read or write traffic because too many requests target the same or a narrow range of partition-key values, causing throttling on that partition even while the table as a whole is under-utilized.
DynamoDB spreads a table across many physical partitions and hashes the partition key to decide where each item lives. Throughput is effectively distributed across partitions, so if one key (or a few keys) attracts most of the traffic, that partition can exceed its share and requests get throttled with ProvisionedThroughputExceededException. Adaptive capacity automatically shifts throughput toward busy partitions and can isolate a very hot key, but it isn't instantaneous and won't rescue a single item above the roughly 1000 WCU / 3000 RCU per-partition ceiling. You avoid hot partitions by choosing high-cardinality, evenly-accessed partition keys and by write-sharding keys that are inherently skewed.
- Even key design keeps throughput usable across the whole table
- Avoids throttling despite adequate provisioned/on-demand capacity
- Predictable low latency under high concurrency
- Prevents a single popular item from bottlenecking the service
- Lower cost by not over-provisioning to compensate for skew
AI Mentor Explanation
Picture a stadium with dozens of ticket gates, but everyone crowds the one gate nearest the car park while the rest stand empty. That single gate jams and turns people away even though the stadium could easily admit the crowd. A hot partition is that jammed gate: one partition key soaking up all the traffic. Spreading fans across every gate — a well-distributed key — lets the whole capacity actually be used.
Step-by-Step Explanation
Step 1
Understand partitioning
DynamoDB hashes the partition key and stores items across many physical partitions, each with its own throughput share.
Step 2
Spot the skew
Identify keys where a few values (a viral item, 'status=active', today's date) attract most reads or writes.
Step 3
Choose a high-cardinality key
Pick a partition key with many distinct, evenly-accessed values so traffic spreads across partitions.
Step 4
Write-shard skewed keys
Append a suffix or hash bucket (e.g. deviceId#3) to fan a hot key across N logical partitions, then scatter-gather on read.
Step 5
Lean on adaptive capacity, but design around limits
Adaptive capacity rebalances automatically, yet a single item still caps near 1000 WCU / 3000 RCU — design so no one item needs more.
What Interviewer Expects
- Explains how DynamoDB hashes the partition key across physical partitions
- Links skewed access to throttling despite available table capacity
- Knows adaptive capacity exists but is not a silver bullet
- Recommends high-cardinality, evenly-accessed partition keys
- Describes write sharding for inherently hot keys
Common Mistakes
- Using a low-cardinality attribute (status, boolean, date) as the partition key
- Blaming provisioned throughput when the real issue is key distribution
- Assuming adaptive capacity instantly fixes any hotspot
- Ignoring the per-partition WCU/RCU ceiling for a single item
- Sharding on write but forgetting the scatter-gather cost on read
Best Answer (HR Friendly)
“A hot partition is when one slice of your database gets flooded with traffic because too many requests point at the same key, so it gets throttled even though the rest of the table is idle. You avoid it by choosing a key with lots of well-spread values, and splitting any naturally popular key across several buckets.”
Code Example
// A single popular key like 'sensor#42' would hammer one partition.
// Spread its writes across N shards, then read all shards back.
const SHARDS = 10
function shardedKey(sensorId) {
const shard = Math.floor(Math.random() * SHARDS)
return `${sensorId}#${shard}` // e.g. sensor#42#7
}
async function writeReading(sensorId, value) {
await ddb.send(new PutCommand({
TableName: 'Readings',
Item: { pk: shardedKey(sensorId), ts: Date.now(), value },
}))
}
async function readAll(sensorId) {
const queries = Array.from({ length: SHARDS }, (_, s) =>
ddb.send(new QueryCommand({
TableName: 'Readings',
KeyConditionExpression: 'pk = :pk',
ExpressionAttributeValues: { ':pk': `${sensorId}#${s}` },
})))
const results = await Promise.all(queries) // scatter-gather across shards
return results.flatMap(r => r.Items)
}Follow-up Questions
- What is DynamoDB adaptive capacity and how does it help with hot partitions?
- What are the per-partition throughput limits for a single item?
- How does write sharding trade write simplicity for read complexity?
- How would a Global Secondary Index create its own hot partition?
- How can time-based keys (like a date) cause hot partitions and how do you fix it?
MCQ Practice
1. A hot partition most directly results from?
A hot partition occurs when traffic concentrates on a narrow set of partition-key values, overloading their physical partition.
2. Which partition key choice best avoids hot partitions for a high-traffic table?
High-cardinality, evenly-accessed keys spread requests across many partitions; low-cardinality keys concentrate them.
3. What technique fans an inherently popular key across many partitions?
Appending a shard suffix (e.g. key#3) distributes writes across N logical partitions, read back via scatter-gather.
Flash Cards
What is a hot partition? — A single physical partition overloaded because traffic concentrates on a few partition-key values, causing throttling.
How does DynamoDB place items? — It hashes the partition key to assign each item to one of many physical partitions.
What is write sharding? — Appending a suffix/hash bucket to a hot key to spread its writes across N partitions, reading via scatter-gather.
Does adaptive capacity fully solve hot partitions? — No. It rebalances automatically but isn't instant and can't exceed the per-item throughput ceiling.
Continue Learning
Related Interview Questions
How does DynamoDB partitioning and data distribution work under the hood?
hard
How does DynamoDB adaptive capacity work, and why can you still get throttled?
hard
How do you design partition keys for even data distribution in DynamoDB?
hard
What is a partition key in DynamoDB and how does it distribute data?
medium