DynamoDB Partition Key — Hot Partitions & Key Design
Reviewed by Gurusankar M. · Updated Aug 24, 2026
⚡ Short Answer
DynamoDB distributes data across partitions by the partition key's hash. If many requests target one key (or a low-cardinality key), that partition gets 'hot' — throttling even when total capacity is fine. Choose a high-cardinality, evenly-accessed key; add a suffix/sharding for hot keys.
☕Coffee Chat Question
Concept Made Simple
“How does the DynamoDB partition key affect performance, and what is a hot partition?”
🧠Mind Map Answer
Remember It Faster
The partition key (hash key) is the attribute DynamoDB hashes to decide which physical partition stores an item. It's how DynamoDB scales horizontally — every item's partition key hash maps to one of many partitions, so read/write load spreads across the fleet instead of hitting a single server. There's no ad-hoc query flexibility like SQL: you look up by partition key (and optionally a sort key or GSI), so access patterns have to be known before the table is designed.
| Partition Key | Sort Key | |
|---|---|---|
| Required? | Always | Optional |
| Determines | Which partition stores the item (hash) | Item order/uniqueness within that partition |
| Query support | Exact match only (=) | Range, begins_with, between |
| Uniqueness | Must be unique alone, unless paired with a sort key | PK + SK together must be unique |
A concrete before/after: a table partitioned by status (3 values — pending/shipped/delivered) versus the same table repartitioned by userId (millions of distinct values).
| Bad key: status (3 values) | Good key: userId (millions of values) | |
|---|---|---|
| Distinct key values | 3 | ~1 per user — millions |
| Where traffic lands | Every request collapses onto one of 3 partitions | Requests spread across hundreds of partitions |
| Per-partition ceiling | Hit almost immediately, no matter total provisioned capacity | Each partition stays well under AWS's per-partition throughput ceiling |
| Result at scale | Throttled (ProvisionedThroughputExceededException) even with capacity to spare table-wide | Throughput scales close to linearly with provisioned capacity |
This doesn't mean low-cardinality attributes like status are unusable — they just can't be the partition key. Keep the high-cardinality id (e.g. orderId) as the partition key, and put status in a sort key or a Global Secondary Index instead. You still get an efficient "all orders with status = shipped" query via the GSI, but writes spread across partitions by orderId instead of collapsing onto one of three.
Adaptive capacity helps, but only up to a point. DynamoDB continuously monitors traffic per partition and, when it detects a hot partition, transparently isolates that partition's keys and boosts throughput toward it — instantly for isolated hot keys since 2019, without any table resizing or manual intervention. What it can't do is rescue a pathologically low-cardinality key design: adaptive capacity can boost one hot partition's share of the table's total provisioned throughput, but it can't manufacture throughput the table doesn't have, and a 3-value partition key still means only 3 physical partitions exist to receive that boosted share, capping how far it can stretch. Adaptive capacity buys headroom for uneven access on an otherwise reasonable key; it's not a substitute for high-cardinality key design.
Time-based keys are the sneaky version of a low-cardinality key — the partition key itself may have plenty of distinct values over the table's lifetime (2026-09-01, 2026-09-02, ...), so it doesn't look low-cardinality at a glance. The problem is access pattern, not key design: almost all reads and writes target today's date, so at any given moment traffic still collapses onto whichever single partition represents "now," while every other date's partition sits idle. The fix is the same write-sharding idea from above, applied proactively: suffix the date with a shard number (2026-09-15#3) so "today" is spread across multiple partitions even while it's the only date anyone's writing to, rather than discovering the hot-partition problem only once a single calendar day's traffic exceeds one partition's throughput ceiling.
⌨️Hands-on Keyboard
Learn by Doing
// Write sharding: spread a hot partition key across N logical shards
// so no single physical partition absorbs all the write traffic.
int shardCount = 10;
String hotKey = "sensor-42"; // naturally low-cardinality / bursty
int shard = ThreadLocalRandom.current().nextInt(shardCount);
String shardedPk = hotKey + "#" + shard; // e.g. "sensor-42#7"
PutItemRequest put = PutItemRequest.builder()
.tableName("Readings")
.item(Map.of(
"pk", AttributeValue.fromS(shardedPk), // spread across 10 partitions
"sk", AttributeValue.fromS(Instant.now().toString()),
"value", AttributeValue.fromN(String.valueOf(reading))))
.build();
ddb.putItem(put);
// Reads must now fan out across all shards and merge results client-side —
// that's the cost of sharding: writes get cheap, reads get more complex.
List<QueryRequest> shardQueries = IntStream.range(0, shardCount)
.mapToObj(i -> QueryRequest.builder()
.tableName("Readings")
.keyConditionExpression("pk = :pk")
.expressionAttributeValues(Map.of(":pk", AttributeValue.fromS(hotKey + "#" + i)))
.build())
.toList();10 physical partitions absorb the write load instead of 1; queries fan out and merge.
🔥What If?
Think Beyond the Expected
A table partitioned by 'status' (only 3 values) throttles under load — why and fix?
Only 3 partition-key values means traffic concentrates on 3 partitions → hot partitions and throttling regardless of provisioned capacity. Use a high-cardinality key (e.g. entity id) and put status in a GSI/sort key, or shard the hot key with a suffix.
😂Real World
Hot-partition throttling from low-cardinality or skewed keys is the #1 DynamoDB performance pitfall; key design (and write sharding for hotspots) is the fix, not raising capacity. The write-sharding pattern above is the standard escape hatch when an attribute is inherently hot (a trending item, a single IoT sensor, a viral post) and can't simply be swapped for a different key.
🎯Interviewer's Expectation
Keywords they're listening for:
⚠️Common Mistakes
- ✗Low-cardinality partition keys
- ✗Time-based keys causing hot 'current' partition
- ✗Raising capacity to fix skew (doesn't)
✅Best Practices
- ✓Choose high-cardinality, evenly-accessed keys
- ✓Shard hot keys with a suffix
- ✓Design keys around access patterns
🔁Follow-up Questions
- 1What is a DynamoDB partition key?
- 2How does DynamoDB distribute data across partitions?
- 3What makes a partition key 'high-cardinality', and why does it matter?
- 4Partition key vs sort key — what's the difference?
- 5How does adaptive capacity help (and not)?
- 6How do you shard a hot write key?
🧩Related Technologies
📚References
Continue Learning with AI
Take this question deeper with your favourite AI assistant. Pick a depth, copy the prompt, or open it directly — AI is your learning companion, not a shortcut.
Plain-language foundations
I'm preparing for a software engineering interview and want to understand this from scratch, as a beginner. Topic: DynamoDB (AWS) Interview question: "How does the DynamoDB partition key affect performance, and what is a hot partition?" Please: 1. Explain the core idea in simple, plain language, using an everyday analogy. 2. Define any technical terms you use. 3. Walk through one small, concrete example. 4. Finish with a single sentence I can easily remember. Keep the tone friendly and assume I'm new to this topic.
Was this answer helpful?
⭐ Featured Products
Support our platform by exploring our recommended products.
As an Amazon affiliate, purchases through these links may earn us a small commission — at no extra cost to you. It helps keep Full Stack Interview Guru free.