Dynamodb medium
In 'Single Table Design', why are generic primary key names like `PK` and `SK` used instead of descriptive names like `UserID` and `OrderID`?
- A To reduce the storage overhead of the JSON keys in the underlying database files.
- B Key Overloading: It allows storing multiple diverse entity types in the same physical partitions, enabling complex queries that fetch related data in a single round-trip using prefix-based lookups.
- C It is required for the application to be compatible with older versions of the AWS SDK.
- D To make the data intentionally difficult for unauthorized users to read (Obfuscation).
Answer: B. Key Overloading: It allows storing multiple diverse entity types in the same physical partitions, enabling complex queries that fetch related data in a single round-trip using prefix-based lookups.
By using generic keys, you can store `USER#123` and `ORDER#456` in the same table. This allows for 'pre-joined' data. For instance, you could model a user and their orders under the same Partition Key, allowing a single `Query` to fetch both in one network call, fulfilling a complex UI requirement efficiently.
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- DynamoDB has a strict 400KB limit on the size of a single item. What is the recommended design pattern if you need to store larger documents (e.g., 5MB PDFs)?
- What is the primary role of the 'Partition Key' in ensuring DynamoDB's infinite horizontal scalability?
- Why is the `Query` operation generally preferred over `Scan` for production workloads in DynamoDB?
- DynamoDB is a 'fully managed' serverless database. What is a primary operational benefit of this model for an engineering team?
- In 'Provisioned Capacity' mode, how is the performance budget of a DynamoDB table defined?
- When would an architect choose to implement DAX (DynamoDB Accelerator) in front of an existing DynamoDB table?