Introduction

The Partition Key and Sort Key are the heart of every DynamoDB table design.

Unlike relational databases where indexes can be added later, in DynamoDB your primary key design determines your application's scalability, performance, and cost.

Poor key design can lead to:

• Hot Partitions
• High Latency
• Request Throttling
• Increased Costs

A good key design provides:

• Even Data Distribution
• Millisecond Response Time
• Efficient Queries
• Massive Horizontal Scaling

Understanding Partition Keys and Sort Keys is one of the most frequently asked DynamoDB interview topics.

---

DynamoDB Request Flow

flowchart LR

Application --> PartitionKey --> HashFunction --> PhysicalPartition --> SortKey --> Items

---

1. What is a Primary Key?

Answer

Every DynamoDB table requires a Primary Key.

Two options exist:

• Partition Key
• Composite Primary Key (Partition Key + Sort Key)

The primary key uniquely identifies an item.

---

2. What is a Partition Key?

Partition Key determines

• Where data is stored
• Which physical partition stores the item
• How data is distributed

Example

CustomerId

---

Partition Key Flow

flowchart LR

CustomerId --> HashFunction --> Partition --> StorageNode

---

3. How does DynamoDB use the Partition Key?

Steps

1. Read Partition Key
2. Calculate Hash
3. Generate Hash Value
4. Locate Physical Partition
5. Store Item

---

4. What is a Sort Key?

Sort Key determines

• Item ordering
• Range Queries
• Multiple items within the same partition

Example

OrderDate

---

5. What is a Composite Primary Key?

Combination of

Partition Key

+

Sort Key

Example

CustomerId

+

OrderDate

---

Composite Key Architecture

flowchart LR

CustomerId --> Partition --> OrderDate --> SortedItems

---

6. Difference between Partition Key and Sort Key?

Partition Key	Sort Key
Determines storage location	Determines item order
Mandatory	Optional
Uses Hash Function	Uses Lexicographical Order
One Value per Item	Supports Multiple Items

---

7. Can two items have the same Partition Key?

Yes.

If a Sort Key exists.

Example

CustomerId = 1001

Order1

Order2

Order3

---

8. Can two items have the same Composite Primary Key?

No.

Combination must always be unique.

Example

CustomerId

+

OrderDate

Must uniquely identify an item.

---

9. What is a Physical Partition?

DynamoDB internally stores data inside physical partitions.

AWS automatically creates

• New Partitions
• Splits Partitions
• Moves Data

Developers never manage partitions manually.

---

Physical Partition

flowchart LR

PartitionKey --> Hash --> PhysicalPartition1

PartitionKey2 --> Hash --> PhysicalPartition2

---

10. How does DynamoDB distribute data?

Using

Hash(Partition Key)

Items with different hash values are distributed across multiple physical partitions.

---

11. What is Hashing?

Hashing converts

CustomerId

↓

Unique Hash Value

↓

Partition

This ensures even distribution.

---

12. Why is a good Partition Key important?

Benefits

• Balanced Load
• Better Scalability
• Faster Reads
• Faster Writes
• Lower Cost

---

13. What is a High Cardinality Partition Key?

A key with many unique values.

Example

CustomerId

EmployeeId

OrderId

Recommended.

---

14. What is a Low Cardinality Partition Key?

Few unique values.

Example

Status

Gender

Country

Not recommended.

---

15. What is a Hot Partition?

One partition receives excessive traffic.

Example

Partition Key

Status = ACTIVE

Millions of requests

↓

One partition

↓

Throttling

---

Hot Partition

flowchart LR

MillionsOfRequests --> SinglePartition --> HighCPU --> Throttling

---

16. How do you avoid Hot Partitions?

• Choose High Cardinality Keys
• Randomize Keys
• Add Bucketing
• Add Suffixes
• Review Access Patterns

---

17. What is Bucketing?

Bucketing distributes data across multiple partition keys.

Instead of

CustomerId

Use

CustomerId#2026

CustomerId#2027

or

CustomerId#01

CustomerId#02

---

Bucketing Example

Customer1001#01

Customer1001#02

Customer1001#03

---

18. How is the Sort Key stored?

Items sharing the same Partition Key are sorted by Sort Key.

Example

Customer1001

↓

2024

↓

2025

↓

2026

---

19. What queries require a Sort Key?

Examples

• Latest Orders
• Orders Between Dates
• Employee History
• Banking Transactions

---

20. Range Query Example

CustomerId = 1001

AND

OrderDate

BETWEEN

2024-01-01

AND

2024-12-31

---

21. Begins_With Example

CustomerId=1001

AND

begins_with(OrderId,"ORD")

Useful for prefixes.

---

22. Sort Key Comparison Operators

Supported

• =
• <
• <=

• =

• BETWEEN
• begins_with()

---

23. Query without Sort Key

Possible.

Returns

All items

for the Partition Key.

---

24. Query without Partition Key

Not possible using Query API.

Must use

Scan

which is slower and more expensive.

---

25. What is an Access Pattern?

Access Pattern describes how applications retrieve data.

Examples

• Customer Orders
• Latest Transactions
• Orders by Date
• Device Events

Primary keys should always be designed around access patterns.

---

26. Single Table Design

One table stores multiple entities.

Example

Customer

Order

Invoice

Payment

Uses

Composite Keys

to support multiple query patterns.

---

Single Table Example

PK = CUSTOMER#1001

SK = PROFILE

PK = CUSTOMER#1001

SK = ORDER#1001

PK = CUSTOMER#1001

SK = PAYMENT#500

---

27. Banking Example

Partition Key

AccountId

Sort Key

TransactionTime

Benefits

• Latest Transactions
• Monthly Statements
• Fast Reads

---

28. IoT Example

Partition Key

DeviceId

Sort Key

Timestamp

Supports

• Sensor History
• Time-Series Queries

---

29. E-Commerce Example

Partition Key

CustomerId

Sort Key

OrderDate

Supports

• Order History
• Latest Orders
• Order Timeline

---

Enterprise Best Practices

• Design keys based on access patterns.
• Prefer high-cardinality partition keys.
• Avoid hot partitions.
• Use composite keys whenever multiple related items exist.
• Keep item collections balanced.
• Prefer Query over Scan.
• Test partition distribution before production.
• Monitor CloudWatch throttling metrics.
• Use adaptive capacity with proper key design.
• Review key design before every schema change.

---

Quick Revision

Topic	Key Point
Partition Key	Data Distribution
Sort Key	Item Ordering
Composite Key	Partition + Sort
Hash Function	Finds Partition
Physical Partition	Internal Storage
High Cardinality	Recommended
Low Cardinality	Avoid
Hot Partition	Performance Issue
Range Query	Sort Key
Query	Uses Partition Key
Scan	Full Table Scan
Bucketing	Prevent Hot Partitions

---

Interview Tips

Interviewers frequently ask

• What is a Partition Key?
• Explain Sort Key.
• Difference between Partition Key and Sort Key.
• What is a Composite Primary Key?
• What is a Hot Partition?
• How do you avoid Hot Partitions?
• Why can't Query work without a Partition Key?
• Explain Single Table Design.
• Give a banking example using Partition and Sort Keys.
• How does DynamoDB distribute data internally?

Always explain access patterns first, then justify your key design. In production, the success of a DynamoDB application depends more on choosing the correct Partition Key than on almost any other design decision.

---

Summary

Partition Keys and Sort Keys form the foundation of every DynamoDB table. The Partition Key determines how data is distributed across physical partitions, while the Sort Key organizes related items within a partition and enables efficient range queries.

Designing keys around application access patterns, selecting high-cardinality partition keys, preventing hot partitions, and leveraging composite primary keys are essential techniques for building scalable, high-performance DynamoDB applications that support millions of requests with predictable latency.