Ravindra BagaleCourses & study guides मराठी Track your progress

DynamoDB Partition Keys, Sort Keys and Hot Partitions Explained

By , trainer LinkedIn Last updated:

After modeling, traffic can still crush one partition. Lagos fintech lead Chioma Adeyemi saw ProvisionedThroughputExceeded on USER#celebrity during a sale. This chapter covers partition/sort keys, hot partitions, write sharding and CloudWatch clues. Modeling chapter: Data modeling.

What you'll learn in this chapter

  • Explain the core idea with an everyday story
  • Apply Why / What / How on the topic
  • Read commands with sample output and meaning
  • Map the idea across industries
  • Complete the lab and cleanup

1. Everyday example: one busy lift in a tower

A tower with 40 flats but only one working lift is a hot partition. Spreading people across lifts is write sharding (USER#id#0..N). Sort keys are the floor buttons — they order stops inside one lift shaft (partition).

2. Vertical steps

Why -> What -> How -> Lab -> CleanupWhyWhatHowLabCleanup
Always cleanup lab resources

3. Why do we need this?

Why do we need this?

One popular key absorbs too many reads/writes. DynamoDB partitions have throughput limits. Hot keys cause throttling even when the table has spare capacity overall.

4. What is it?

What is it?

Partition key places items; sort key orders inside the partition. Hot partition = one key overloaded. Fixes: more specific keys, write sharding suffixes, cache, or GSI fan-out for reads.

5. How to do it (step by step)

How to do it (step by step)

  1. Estimate peak ops/sec per PK.
  2. Avoid low-cardinality PKs (status=NEW alone).
  3. Add shard suffixes for extreme writers.
  4. Use CloudWatch ThrottledRequests + Contributor Insights.
  5. Re-test after sales/events.

6. Write sharding pattern

PK=USER#u9#0 .. USER#u9#7 for writes; compute shard = hash(requestId)%8. Reads either scatter-gather or use a materialized latest profile item.

7. CloudWatch clues

ThrottledRequests, ReadThrottleEvents, WriteThrottleEvents, SuccessfulRequestLatency. Contributor Insights lists top keys.

8. Commands with output and meaning

aws dynamodb describe-table --table-name lab-dda-shop --query 'Table.KeySchema'
# Output: HASH PK, RANGE SK — confirms key roles
aws cloudwatch get-metric-statistics --namespace AWS/DynamoDB --metric-name ThrottledRequests \
  --dimensions Name=TableName,Value=lab-dda-shop --start-time 2026-10-31T00:00:00Z --end-time 2026-10-31T23:59:59Z \
  --period 3600 --statistics Sum --region ap-south-1
# Output: datapoints Sum>0 means throttling happened. Meaning: investigate hot keys, not only table capacity.

KeySchema shows HASH/RANGE roles. ThrottledRequests>0 means some partition was hot — raise shard count or redesign PK.

9. Industry stories

  • Gaming (Carlos Rivera, Mexico City): shard score writes GAME#id#0..15.
  • IoT (Mei Lin, Shenzhen): device#day PK spreads days.
  • Retail flash sale (Rohit Sharma, Mumbai): product PK too hot — shard + DAX later.
  • Social (Elena Petrova, Warsaw): celebrity feed PK sharded.
  • Ads (Kenji Watanabe, Osaka): campaign#geo shards.

10. Lab

How to do it (step by step)

  1. Create table; hammer one PK with a loop of puts; watch ThrottledRequests.
  2. Add shard suffix; retry; compare throttles.
  3. Delete lab table.

Cleanup (stop billing)

  1. Delete lab tables, indexes, and triggers you created.
  2. Confirm with describe-table that names are gone.

11. Access-pattern workshop (paper first)

  1. List every screen or API that reads or writes data.
  2. For each: write the exact key lookup or query shape in plain English.
  3. Mark 1:1, 1:many, many:many relationships.
  4. Circle anything that needs a sort range (time, status, score).
  5. Only then invent PK/SK and optional GSI keys.
  6. Estimate peak items per partition key per second.
  7. Write one sample item JSON for each entity type.
  8. Peer-review with someone who did not design it.

12. Copy-paste DynamoDB CLI starters

# Region habit for this series
export AWS_DEFAULT_REGION=ap-south-1

# Describe + sample
aws dynamodb describe-table --table-name ShopApp
aws dynamodb scan --table-name ShopApp --max-items 3

# Query by PK (replace names)
aws dynamodb query --table-name ShopApp   --key-condition-expression "PK = :pk"   --expression-attribute-values '{":pk":{"S":"USER#u123"}}'

# On-demand capacity mode check
aws dynamodb describe-table --table-name ShopApp   --query 'Table.BillingModeSummary'

# Streams status
aws dynamodb describe-table --table-name ShopApp   --query 'Table.StreamSpecification'

13. More industry stories

  • Retail (Aisha Khan, Dubai): single-table cart+orders; PK=USER#id keeps each shopper hot path local.
  • Gaming (Carlos Rivera, Mexico City): leaderboard uses sparse GSI on score; write shard on hot gameId.
  • IoT (Mei Lin, Shenzhen): sensor#day PK + timestamp SK; TTL 30 days keeps storage flat.
  • Healthcare (Rohan Deshmukh, Pune): appointment slots use conditional Put — no double book.
  • Fintech (Elena Petrova, Warsaw): Streams fan-out to audit table; never update audit in place.
  • Travel (Omar Haddad, Amman): global tables for read-local catalog; writes region-sticky for inventory.

14. Glossary (short)

TermMeaning
PK / Partition keyHash key that places the item in a partition
SK / Sort keyOrders items inside a partition; enables ranges
Item collectionAll items that share the same PK
GSIGlobal Secondary Index — alternate PK/SK, own partitions
LSILocal Secondary Index — same PK, different SK
RCU / WCURead/Write Capacity Units on provisioned mode
Conditional writeWrite succeeds only if a condition is true
Stream view typeKEYS_ONLY / NEW_IMAGE / OLD_IMAGE / NEW_AND_OLD_IMAGES

15. Practice: explain out loud

  1. 60s: why access patterns come before table design.
  2. 60s: hot partition and one fix (write sharding).
  3. 60s: GSI vs LSI in one breath.
  4. 60s: on-demand vs provisioned for a startup.
  5. 60s: optimistic locking with a version attribute.
  6. 60s: Streams + Lambda for an audit trail.
  7. Record once; cut filler; record again.

16. Safe lab hygiene

  • Use ap-south-1 labs with a budget alert (₹/USD).
  • Prefix lab tables with lab- and your initials.
  • Prefer on-demand for tiny labs unless you are learning auto scaling.
  • Delete tables and Lambda triggers after the lab.
  • Never point Streams consumers at production without a DLQ.
  • Tag every resource Owner + Expiry.

18. Single-table sketch pad

Write entities as rows in one mental table before you open the console. Example for a small shop: USER#, ORD#, ORD#|ITEM#, PROD# under carefully chosen PK/SK.

EntityPKSKExample attrs
UserUSER#u1PROFILEname, city
OrderUSER#u1ORD#2026-10-31#o9total, status
Order itemORD#o9ITEM#sku1qty, price
ProductPROD#sku1METAtitle, stock

19. Ten oral drill questions

  1. What is an access pattern?
  2. Why overload PK with entity prefixes?
  3. Name one hot-partition symptom.
  4. Sparse GSI means what?
  5. When is LSI impossible after create?
  6. On-demand bills for what?
  7. What does attribute_not_exists do?
  8. NEW_AND_OLD_IMAGES costs more — why still pick it?
  9. How do you stop a poison Streams message loop?
  10. Which existing chapter do you open for PutItem syntax?

20. Capacity and throttle drill

  1. Open CloudWatch for your table: ConsumedReadCapacityUnits, ConsumedWriteCapacityUnits, ThrottledRequests.
  2. Note whether BillingMode is PAY_PER_REQUEST or PROVISIONED.
  3. If provisioned, write current RCU/WCU and autoscaling min/max.
  4. Name your hottest expected PK in one sentence.
  5. Write one mitigation: shard, cache, or redesign.
  6. Set or verify a budget alert for DynamoDB.
  7. Check GSI list and whether each is still used.
  8. Confirm Streams enabled only where consumers exist.

21. Condition expression cheatsheet

# Create-once
attribute_not_exists(PK)

# Optimistic lock
version = :v

# Stock / seat
stock > :zero
#status = :free

# Combine
attribute_not_exists(PK) AND #type = :user

Meaning: conditions are the seatbelt for concurrent writers. Put them on every race-prone update. Full SDK samples stay in the SDK chapter — here we only list the expressions you will reuse.

22. Streams consumer checklist

  • View type matches need (KEYS_ONLY vs NEW_AND_OLD).
  • Lambda has DLQ and retry policy.
  • Handler idempotent on eventID or keys.
  • IteratorAge alarm before users feel lag.
  • No accidental write-loop back into the same table without markers.
  • Fan-out via SNS/EventBridge when >1 consumer team.
  • Disable stream when lab ends.
  • Ch1 Modeling -> Ch2 Hot keys -> Ch3 GSI/LSI -> Ch4 Capacity -> Ch5 Transactions -> Ch6 Streams.
  • Always link intro + CRUD + CLI + SDK instead of rewriting Put/Get.
  • Projects P1-P7 come in later batches and reuse these ideas.

24. Extra oral drills

  1. Explain single-table to a product manager in 45 seconds.
  2. Draw PK/SK for a chat thread on a whiteboard.
  3. Name three CloudWatch metrics for DynamoDB pain.
  4. Say when you would refuse a new GSI request.
  5. Describe one transaction for seat + payment record.
  6. Explain why Streams are at-least-once.
  7. Convert a Scan-based feature request into a Query design.
  8. List cleanup steps after a DynamoDB lab.

25. Teacher story: the notebook that became a database

Ravindra once watched a shop keep every customer, order and payment in one paper notebook. Finding last Tuesday's unpaid bills meant flipping pages. DynamoDB single-table thinking is that notebook done carefully: one place, clear labels (PK/SK), and an index tab (GSI) only when a second way to find rows is worth the cost. Do not photocopy the notebook into ten unrelated books unless the shop truly has ten separate businesses.

When Meera (clinic), Omar (travel), and Aisha (retail) design together, they still start on paper: screen list, key sketch, sample JSON, peer review. Console clicks come last. That ritual is why this deep series links the intro and CRUD chapters instead of rewriting PutItem on every page.

26. Sixteen mini tasks (self-check, leak-free)

  1. Write three access patterns for a cart app in one minute.
  2. Invent PK/SK for user profile and orders under that user.
  3. Name one hot-partition anti-pattern.
  4. Explain write sharding to a teammate in 40 seconds.
  5. Say GSI vs LSI without notes.
  6. Pick KEYS_ONLY or ALL for a sparse open-orders index — why?
  7. Choose on-demand or provisioned for a weekend flash sale.
  8. List five DynamoDB bill line-item types.
  9. Write a create-once condition in words.
  10. Describe optimistic locking with a version attribute.
  11. When do you wrap two writes in a transaction?
  12. Pick a stream view type for an audit log — justify.
  13. Name two Stream consumer safety rules.
  14. What CloudWatch metric shows stream lag?
  15. Which linked chapter has PutItem CLI syntax?
  16. Write your lab cleanup checklist (table, stream, lambda, alarms).

27. Marathi classroom lines (say out loud)

  • Access patterns आधी, keys नंतर — हे mantra आठवा.
  • Hot partition म्हणजे एक PK वर गर्दी — shard किंवा redesign.
  • GSI लवचिक; LSI create-time — चुकीचा index महाग.
  • On-demand म्हणजे वापरल्यावर पैसे; provisioned म्हणजे आरक्षित units.
  • Condition आणि transaction म्हणजे race साठी seatbelt.
  • Streams at-least-once आहे — handler idempotent ठेवा.

28. Hindi bridge lines

  • Pehle access patterns likho, baad mein PK/SK.
  • Hot partition ek key par zyada load.
  • GSI kabhi bhi; LSI table banate waqt.
  • On-demand spike ke liye; provisioned steady ke liye.
  • Transaction = sab milkar ya kuch nahi.
  • Streams duplicate de sakte hain — idempotent likho.

29. Common errors and fixes

Each row is a real mistake students and juniors hit. Read the fix before you panic.

Error / symptomFix
PK = status onlyInclude id/tenant.
Ignoring throttle alarmsPage on ThrottledRequests.
Shard count = 1 foreverRevisit after load tests.
Caching forgottenCache hot reads.
GSI with same hot PKGSI can be hot too.
Huge items on hot PKKeep items small.
No Contributor InsightsEnable for top keys.
Blaming on-demand mode onlyMode != hot-key fix.
Skipping load test before saleLoad-test celebrities.

30. Troubleshooting checklist

  1. Throttles but unused capacity: hot key.
  2. Only one user fails: their PK.
  3. After sharding, reads miss: query all shards or keep read model.
  4. GSI throttles: check GSI PK design.
  5. Spike at UTC midnight: time-based PK skew.

31. FAQ

Q. Should I always use a single table?

Often yes for related access patterns; not a religion. Separate tables are fine for unrelated domains or different capacity/security needs.

Q. Do I still need RDS?

Yes for heavy joins, multi-row SQL reports, and strong relational constraints. See the intro DynamoDB vs RDS chapter.

Q. Is Scan evil?

Scan is a tool for rare admin jobs and small tables. Design so hot paths use Query/GetItem.

Q. Where are Put/Get command details?

In the CRUD survey, CLI and SDK chapters — this deep set links them instead of copying.

Q. What is a hot partition?

One PK gets disproportionate traffic.

Q. Write sharding?

Append shard ids to PK and spread writes.

Q. Does on-demand remove hot keys?

No — still partition limits.

Q. Sort key role?

Order/range inside partition.

32. Interview Q&A

Q. (B) PK vs SK?

PK places partition; SK orders inside.

Q. (B) Hot partition symptom?

Throttles on one key.

Q. (M) Write sharding how?

PK#shardN; random/hash choose shard.

Q. (M) Low cardinality risk?

Few PK values = few partitions.

Q. (S/MNC) Celebrity user design?

Shard writes; cache profile; isolate feed.

Q. (MNC) Prove fix?

Before/after ThrottledRequests + latency.

33. Tips in English, Marathi and Hindi

Ravindra Bagale's Tip (EN)

Measure per-key traffic before adding capacity.

Ravindra Bagale's Tip (MR)

Capacity आधी per-key मोजा.

Tip (HI)

पहले per-key traffic नापें।

Try at home

  1. List top 5 busiest keys in your app.
  2. Sketch a shard plan for one of them.
  3. Read modeling chapter once more.

In short

  1. PK places; SK orders.
  2. Hot key != table out of capacity.
  3. Shard, cache, redesign.
  4. Watch ThrottledRequests.

Revision, interview and comparison cards

Revise this lesson in a few minutes. Save the cards on your phone or download them as PNG files. The QR code on each card opens this lesson.

Revision card: Spot a hot partition. One popular PK absorbs traffic and throttles everyone sharing it. Low-cardinality keys, STATUS=ACTIVE queues, single leaderboard PK — classic heats. CloudWatch throttles → Contributor Insights → shard or redesign. Mei Lin shards gameId writes with #0..#7 suffixes for a launch spike.
Revision card: Spot a hot partition · Download PNG · Open card page
Revision card: Write sharding. A single hot writer key will not scale with more RCU alone. Append shard suffixes; fan-in on read or project to a GSI for aggregates. Estimate peak per PK → pick shard count → document fan-in. Omar Haddad documents shard count next to the table name in the runbook.
Revision card: Write sharding · Download PNG · Open card page
Comparison: Hot PK vs Write-sharded PK. Hot PK: All traffic on one PK; throttles. Write-sharded PK: Suffix shards spread writes.
Comparison: Hot PK vs Write-sharded PK · Download PNG · Open card page
Comparison: Sort key range vs GSI alternate. Sort key range: Range inside item collection. GSI alternate: New access via other PK.
Comparison: Sort key range vs GSI alternate · Download PNG · Open card page
Interview card: What is a hot partition?. Symptom. One PK gets uneven traffic and throttles. Give one fix: write sharding.
Interview card: What is a hot partition? · Download PNG · Open card page
Interview card: How does write sharding work?. Technique. Suffix shards on writes; fan-in or GSI on read. Warn about shard count vs fan-in cost.
Interview card: How does write sharding work? · Download PNG · Open card page
Interview card: Why do we need a sort key?. Basics. Orders items in a partition; enables range Query. Example: timestamp SK for IoT.
Interview card: Why do we need a sort key? · Download PNG · Open card page
Interview card: How do you find hot keys?. Ops. ThrottledRequests + Contributor Insights hottest keys. Then redesign or shard.
Interview card: How do you find hot keys? · Download PNG · Open card page

More cards: Ravi Sir's Cards.

Practice Tasks

About this scenario

Vidarbha Cotton Mills is a textiles business in Nagpur. Ganesh Wankhede looks after its IT and cloud work. They count money in INR and run their AWS resources in the ap-south-1 Region. In the tasks below you do real jobs for them using what this lesson teaches. All names, account IDs, IP addresses and numbers are made up for practice.

0 / 16

Easy Hot partition = uneven traffic — 1

Why: Def.

What to do: Enter 1 if a hot partition gets disproportionate traffic.

How:
  1. Write down the numbers the task gives you.
  2. Work it out step by step on paper.
  3. Type only the final answer in the box.
  4. Click Check answer.

Easy Write sharding spreads writes — 1

Why: Fix.

What to do: Enter 1 if write sharding spreads writes across suffixes.

How:
  1. Write down the numbers the task gives you.
  2. Work it out step by step on paper.
  3. Type only the final answer in the box.
  4. Click Check answer.

Easy SK for ranges — 1

Why: Range.

What to do: Enter 1 if sort keys support range queries in a partition.

How:
  1. Write down the numbers the task gives you.
  2. Work it out step by step on paper.
  3. Type only the final answer in the box.
  4. Click Check answer.

Easy Low-cardinality PK is risky — 1

Why: Anti.

What to do: Enter 1 if a low-cardinality PK like STATUS=ACTIVE can go hot.

How:
  1. Write down the numbers the task gives you.
  2. Work it out step by step on paper.
  3. Type only the final answer in the box.
  4. Click Check answer.

Easy Describe a DynamoDB table

Why: CLI.

What to do: Describe table ShopApp

How:
  1. Read the task and decide which AWS service it is about.
  2. Write aws, then the service name, then the operation (the action word).
  3. Add each needed flag (--name) followed by its value from the task.
  4. Flags can be in any order. Click Check answer.

Easy Hot key YAML note

Why: Note.

What to do: YAML: symptom: throttle, fix: write-sharding.

How:
  1. Start from the top-level keys the task names.
  2. Indent child keys with 2 spaces (no tabs).
  3. Fill in each property with the value from the task.
  4. Click Check answer. Key order does not matter.

Easy PK places the item in a partition — 1

Why: Def.

What to do: Enter 1 if the partition key places the item in a partition.

How:
  1. Write down the numbers the task gives you.
  2. Work it out step by step on paper.
  3. Type only the final answer in the box.
  4. Click Check answer.

Medium ThrottledRequests is a clue — 1

Why: CW.

What to do: Enter 1 if ThrottledRequests helps spot capacity/hot issues.

How:
  1. Write down the numbers the task gives you.
  2. Work it out step by step on paper.
  3. Type only the final answer in the box.
  4. Click Check answer.

Medium Sparse attr for sparse GSI — 1

Why: Sparse.

What to do: Enter 1 if sparse keys/attrs exist only on some items.

How:
  1. Write down the numbers the task gives you.
  2. Work it out step by step on paper.
  3. Type only the final answer in the box.
  4. Click Check answer.

Medium Burst can hide bad design — 1

Why: Trap.

What to do: Enter 1 if burst capacity can hide a bad key design briefly.

How:
  1. Write down the numbers the task gives you.
  2. Work it out step by step on paper.
  3. Type only the final answer in the box.
  4. Click Check answer.

Medium device#day is a common IoT PK — 1

Why: Pattern.

What to do: Enter 1 if deviceId#day style PKs help IoT time-series.

How:
  1. Write down the numbers the task gives you.
  2. Work it out step by step on paper.
  3. Type only the final answer in the box.
  4. Click Check answer.

Medium Scan max 3 items

Why: CLI.

What to do: Scan ShopApp returning at most 3 items

How:
  1. Read the task and decide which AWS service it is about.
  2. Write aws, then the service name, then the operation (the action word).
  3. Add each needed flag (--name) followed by its value from the task.
  4. Flags can be in any order. Click Check answer.

Hard Contributor Insights shows hot keys — 1

Why: Tool.

What to do: Enter 1 if Contributor Insights helps find hottest keys.

How:
  1. Write down the numbers the task gives you.
  2. Work it out step by step on paper.
  3. Type only the final answer in the box.
  4. Click Check answer.

Hard Sharded reads may need fan-in — 1

Why: Read.

What to do: Enter 1 if after write sharding you may fan-in on read or use a GSI.

How:
  1. Write down the numbers the task gives you.
  2. Work it out step by step on paper.
  3. Type only the final answer in the box.
  4. Click Check answer.

Hard Watch ConsumedWriteCapacityUnits — 1

Why: Metric.

What to do: Enter 1 if ConsumedWriteCapacityUnits is a core write metric.

How:
  1. Write down the numbers the task gives you.
  2. Work it out step by step on paper.
  3. Type only the final answer in the box.
  4. Click Check answer.

Hard Mitigate with shard/cache/redesign — 1

Why: Options.

What to do: Enter 1 if mitigations include shard, cache, or redesign.

How:
  1. Write down the numbers the task gives you.
  2. Work it out step by step on paper.
  3. Type only the final answer in the box.
  4. Click Check answer.

See all practice tasks in the Task Hub →