How do you choose a good partition key in DynamoDB?
Pick an attribute with many distinct values that requests spread across evenly, such as user ID or order ID. A key where most traffic hits a few values creates a hot partition that gets throttled.
Explain it simply
Imagine a college fest with ten registration counters. If students are sent by roll number they spread evenly. If everyone is sent by "branch = CSE" and most students are CSE, one counter has a huge queue while nine are idle. DynamoDB partitions behave the same way.
Example
Table: Orders
Bad key : order_date -> today's date gets all the writes (hot)
Bad key : status ("PENDING") -> most items share a few values
Good key : customer_id (partition) + order_id (sort)
-> many customers, traffic spread across partitions
Query pattern: all orders of one customer
Query customer_id = "C101" -> efficient, hits one partition
If one key is still very busy (a viral product):
add a random suffix: "P55#3" and write-shard across several valuesDynamoDB hashes the partition key to decide which physical partition stores the item, so high cardinality and uniform access are the goals. The sort key lets you keep related items together and query ranges.
Design from your access patterns first: list the queries the app needs, then shape keys around them.
What to say in the interview
"A good partition key has high cardinality and spreads reads and writes evenly, like customer ID. I avoid low-variety keys such as status or date alone, which cause hot partitions, and I design keys from the access patterns, adding a sort key for range queries."
Common mistakes
- Using a timestamp as the sole partition key.