Question

Difficulty: HardData Store Operations with Amazon DynamoDB

A developer is managing a logistics tracking application that stores package delivery status in an Amazon DynamoDB table. The table's partition key is PackageIdPackageId and the sort key is CheckpointTimestampCheckpointTimestamp. A background worker periodically retrieves all packages currently marked with a status of In-Transit-DelayedIn\text{-}Transit\text{-}Delayed to generate a real-time dashboard. Currently, the worker performs a ScanScan operation on the table and uses a FilterExpressionFilterExpression to filter by status. As the table has grown to millions of items, the worker is consistently exceeding the table's provisioned read capacity, resulting in ProvisionedThroughputExceededExceptionProvisionedThroughputExceededException errors. Which two changes should the developer make to resolve the throttling issues and optimize the read performance?

  1. Create a Global Secondary Index (GSI) with a sparse partition key attribute that is only populated when the package status is In-Transit-Delayed.Answer
  2. Update the background worker to use the Query API operation on the new GSI to retrieve the delayed packages.Answer
  3. C
    Use a Scan operation with Segment and TotalSegments parameters to run parallel scans on the main table, applying the FilterExpression on each segment.
  4. D
    Increase the provisioned Read Capacity Units (RCUs) on the base table to handle the scan throughput, and implement an exponential backoff algorithm in the application SDK client.
  5. E
    Initialize the AWS SDK DynamoDB client inside the background worker by hardcoding temporary credentials with maximum read privileges.

Answer

Create a Global Secondary Index (GSI) with a sparse partition key attribute that is only populated when the package status is In-Transit-Delayed, and update the background worker to use the Query API operation on this GSI.
The correct solution involves creating a Global Secondary Index (GSI) with a sparse partition key. Because DynamoDB only populates a GSI when the index key attributes are present in the item, this index will only contain the small subset of packages that are delayed. By querying this GSI instead of scanning the entire base table, the developer restricts data retrieval to only the relevant items, which drastically reduces RCU usage and eliminates throttling.

Step-by-Step Solution

1
Identify the performance bottleneck in the data retrieval pattern.
Scanning a large table with a FilterExpression reads all items and discards non-matching ones after consumption, wasting RCU.
To optimize costs and performance, we must transition from a Scan to a Query operation.
2
Design an index that selectively indexes only the required data subset.
Create a GSI with a sparse attribute (e.g., status is only written when equal to the desired status).
DynamoDB does not index items that lack the GSI's partition key, creating a highly efficient sparse index containing only delayed packages.
3
Refactor the read API call in the application code.
Replace the Scan operation with a Query operation targeted at the GSI.
Query operations retrieve only the matching items, consuming RCUs proportional to the returned dataset size rather than the entire table size.

Key Concept

Using Sparse Global Secondary Indexes (GSIs) and the Query API instead of Scan operations to optimize DynamoDB read performance and reduce RCU consumption.
Rate this question