Dynamodb easy
Why is the `Query` operation generally preferred over `Scan` for production workloads in DynamoDB?
- A The `Scan` operation only works on tables with fewer than 10,000 items.
- B A `Query` uses the primary key hashes to jump directly to relevant data, whereas a `Scan` reads every item in the entire table, consuming massive RCU budget and increasing latency.
- C A `Scan` always requires a DAX cache to be enabled for successful execution.
- D A `Query` is only allowed if the table is less than 1 hour old.
Answer: B. A `Query` uses the primary key hashes to jump directly to relevant data, whereas a `Scan` reads every item in the entire table, consuming massive RCU budget and increasing latency.
Scans are 'linear time' (O(N)) operations that touch every item, costing you RCUs for data you might not even need. Queries are 'constant time' (O(1)) lookups using the partition index, making them efficient and cost-effective even as the table grows to terabytes.
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?
- 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?
- DynamoDB supports two types of Primary Keys. What is the fundamental difference between a 'Simple' and a 'Composite' primary key?