Guided architecture tour · 6–8 min
Find orders a second way — DynamoDB and Secondary indexes
Find a customer’s orders without scanning every order in a table.
This tour teaches architecture decisions. Its services are not provisioned in the emulator.
Your goal
Find a customer’s orders without scanning every order in a table.
Why this matters
A shop can fetch an order by its ID, but also needs a list of one customer’s orders. You will add another lookup path, query it, and account for delayed updates.
Words you will use
An index is another way to look up records. A global secondary index can use a different key from the main table. A projection selects which fields the index holds.
How to proceed
Read each situation and choose an answer. The lesson explains the result. Try again if needed, then continue through all three decisions and finish the tour.
1. Start with the question
The table’s main key is orderId. The app also asks for all orders belonging to customer c-8. Choose a lookup design for that common question.
What could avoid a full-table scan?
A global secondary index keyed for the customer lookup.
Design the index around the question you need to answer. A customer key can group that customer’s orders, with a suitable sort key if ordering matters. Adding an index also adds storage and write work.
The customer lookup has its own access path.
Table: orderId
Index: customerId + order time2. Ask the index
The index is ready, and you know customerId is c-8. Choose the request that uses this path to retrieve matching orders.
Which operation matches the task?
Query the index using customerId = c-8.
Query reads items matching the index key condition. Choose projected fields that support the screen. A filter applied after a scan does not turn that scan into an efficient key lookup.
The request follows the customer key instead of reading the whole table.
Query: IndexName=by-customer, customerId=c-83. Allow time for the index
A new order was just saved, but a query of the global secondary index does not show it yet. Choose the explanation to check before saving another order.
What can cause this brief delay?
The index is updated separately and may briefly lag.
Global secondary index reads are eventually consistent: updates take time to appear there. Do not create another order just because a read is briefly behind. Design the confirmation screen around that behavior.
The app handles a short delay without creating a duplicate order.
Successful write → index catches up → later query sees orderPractice, then check your understanding
In the interactive tour, make each decision before seeing the outcome. Wrong answers receive coaching, and replay gives you a fresh attempt without duplicating earned XP.
Read the official AWS documentation for service behavior and production details.