Dynamodb medium
What is the primary architectural advantage of a 'Sparse Index' in a table with billions of rows (e.g., searching for only 'Flagged' items)?
- A It automatically compresses the data using a specialized Gzip variant.
- B Filtering at Source: Since DynamoDB only replicates items into a GSI if they possess the GSI's partition key, the index size (and read cost) remains tiny compared to the base table, making scans on the index extremely efficient.
- C It allows the index to be stored on an HDD instead of an SSD.
- D It prevents any future writes from modifying the flagged items.
Answer: B. Filtering at Source: Since DynamoDB only replicates items into a GSI if they possess the GSI's partition key, the index size (and read cost) remains tiny compared to the base table, making scans on the index extremely efficient.
Sparse indexes are a powerful filtering tool. If only 1,000 items out of 1 Billion are 'Flagged', and you create a GSI on the `IsFlagged` attribute, the GSI only contains 1,000 items. Scanning this GSI is near-instant and costs almost nothing, whereas scanning the 1 Billion row base table would be impossible.
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?