Question

Difficulty: MediumData Store Operations with Amazon DynamoDB

A developer is building a retail application that stores customer order histories in an Amazon DynamoDB table. The base table uses `OrderID` as the partition key. The application needs to support the following two query patterns efficiently:

- Retrieve all orders placed by a specific customer (`CustomerID`) sorted by the order date (`OrderDate`).
- Retrieve all orders that are currently in a `PENDING` status to process them in batches.

Which two database design strategies should the developer implement to meet these requirements with minimal latency and capacity consumption? (Select TWO.)

  1. Create a Global Secondary Index (GSI) with `CustomerID` as the partition key and `OrderDate` as the sort key.Answer
  2. Create a Global Secondary Index (GSI) with `OrderStatus` as the partition key and `OrderID` or `OrderDate` as the sort key.Answer
  3. C
    Use the `Scan` API operation with a `FilterExpression` on `CustomerID` to retrieve and filter the customer's orders.
  4. D
    Create a Local Secondary Index (LSI) with `CustomerID` as the partition key and `OrderDate` as the sort key.
  5. E
    Increase the provisioned read capacity units (RCUs) on the base table to sustain high-throughput scans for orders in the `PENDING` status.

Answer

Create a Global Secondary Index (GSI) with CustomerID as the partition key and OrderDate as the sort key, and create a Global Secondary Index (GSI) with OrderStatus as the partition key and OrderDate as the sort key.
The correct strategies are to create two Global Secondary Indexes (GSIs). The first GSI uses CustomerID as the partition key and OrderDate as the sort key, enabling efficient Query operations for a specific customer's orders sorted by date. The second GSI uses OrderStatus as the partition key and OrderDate as the sort key, allowing the application to query only the PENDING orders directly instead of scanning the entire table.

Step-by-Step Solution

1
Analyze the first query pattern: retrieving orders for a specific CustomerID sorted by OrderDate.
Since CustomerID is not the partition key of the base table (OrderID is), a secondary index is required. Because the partition key of the index must be different from the base table's partition key, it must be a Global Secondary Index (GSI). Setting CustomerID as the partition key and OrderDate as the sort key enables querying orders for a specific customer pre-sorted by date.
To retrieve items sorted by a non-key attribute efficiently using the Query API.
2
Analyze the second query pattern: retrieving orders in a PENDING status.
Because OrderStatus is not the partition key of the base table, scanning the base table to find PENDING orders is highly inefficient. We need a secondary index with OrderStatus as the partition key. Because the partition key is different from the base table, it must be a GSI. We can query this GSI directly to retrieve only PENDING orders.
To avoid scanning the entire base table to find a small subset of items matching a specific status.
3
Evaluate and eliminate incorrect options.
Using Scan with FilterExpression is ruled out because it reads the entire table. Creating an LSI with CustomerID as the partition key is invalid because LSIs must share the base table's partition key (OrderID). Increasing provisioned capacity (RCUs) to sustain scans is a design anti-pattern and cost-inefficient.
To ensure correct database indexing design and optimize performance and cost.

Key Concept

Using Global Secondary Indexes (GSIs) to optimize read performance and support multiple query patterns without scanning the base table.
Estimated Time:2m 0s
Rate this question