DynamoDB Data Modeling and Single-Table Design for Beginners

By Ravindra Bagale, trainer · LinkedIn · Last updated: 31 October 2026

1. Everyday example: one notebook for the whole shop

A kirana notebook: tabs=PK, lines=SK. USER#, ORD#, ITEM# labels share one notebook (single-table). Tax notebook separate. Meera Kulkarni (Pune) keeps patients+appointments together; firmware inventory separate for IAM.

2. Vertical steps

3. Why do we need this?

Why do we need this?

DynamoDB rewards questions first. Attribute-first design causes Scans that get slow and costly. Hot paths must be GetItem or Query on one partition.

4. What is it?

What is it?

Single-table stores many entity types with overloaded PK/SK prefixes. Related items share a PK for one Query. Multi-table fits unrelated domains or different IAM/backup.

5. How to do it (step by step)

How to do it (step by step)

1. Write 5-15 access patterns in English.
2. Pick PK so hot patterns hit one partition.
3. Pick SK for ranges/begins_with (ISO dates).
4. Add EntityType for filters/Streams.
5. Draw 8-10 sample items.
6. Add GSI/LSI only for leftover patterns later.

6. CartLite key sketch

PK=USER#u100 SK=PROFILE; SK=ORD#2026-10-31T09:15#o2; PK=ORD#o2 SK=ITEM#sku9; PK=PROD#sku9 SK=META. Query USER for orders; Query ORD for lines.

7. Many-to-many edges

Kenji Watanabe (Osaka): STUD#/COURSE# and reverse edges. Thin edges; META for heavy fields; transactions in chapter 5.

8. Commands with output and meaning

aws dynamodb create-table --table-name lab-dda-shop \
  --attribute-definitions AttributeName=PK,AttributeType=S AttributeName=SK,AttributeType=S \
  --key-schema AttributeName=PK,KeyType=HASH AttributeName=SK,KeyType=RANGE \
  --billing-mode PAY_PER_REQUEST --region ap-south-1
# Output: TableStatus CREATING then ACTIVE
aws dynamodb put-item --table-name lab-dda-shop --item '{"PK":{"S":"USER#u100"},"SK":{"S":"PROFILE"},"EntityType":{"S":"User"},"name":{"S":"Ananya Rao"}}'
aws dynamodb query --table-name lab-dda-shop --key-condition-expression "PK = :pk" --expression-attribute-values '{":pk":{"S":"USER#u100"}}'
# Output: Count>=1. Meaning: item collection for that user PK.

create-table = on-demand HASH+RANGE lab. put-item adds User. query by PK returns the collection — the single-table read pattern.

9. Industry stories

• Retail (Diego Alvarez + Ananya Rao): CartLite USER# orders; ORD# lines.
• Logistics (Fatima Zahra, Casablanca): SHIP#+EVT# timeline.
• EdTech (Sofia Alvarez, Bogota): CLASS#+POST# feed.
• Bank (Lucas Meyer, Berlin): ledger vs marketing separate.
• SaaS (Omar Haddad, Amman): TEN# tenant PK.
• Media (Priya Nair, Kochi): watchlist with profile; invoices separate.

10. Lab

How to do it (step by step)

1. Write 6 CartLite patterns; draw samples.
2. Create lab-dda-shop; Put; Query USER# and ORD#.
3. Delete 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)

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.

17. How this set links other chapters

• What Is Amazon DynamoDB? — NoSQL vs RDS, first keys.
• CRUD, Query, Scan, GSI, TTL — basics we deepen, not copy.
• AWS CLI DynamoDB — command catalog.
• AWS SDK DynamoDB — SDK + light conditionals.
• Serverless project builds that *use* DynamoDB — we link, not rebuild.

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.

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.

23. Link map for this deep set (batch 1)

• 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.

30. Troubleshooting checklist

1. Empty Query: PK string + region.
2. Wrong order: SK not sortable.
3. Missing lines: under ORD# PK.
4. Throttle one user: hot partition next ch.
5. Need joins: DynamoDB vs RDS intro.

31. FAQ

32. Interview Q&A

33. Tips in English, Marathi and Hindi

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.

More cards: Ravi Sir's Cards.