Write the access patterns first
Before designing a DynamoDB table, list the operations the application must support. For an order service, those might include fetching one order and listing a customer's orders in a time range.
A key design that makes those operations direct is more useful than one copied from a relational schema.
Sketch a customer-order collection
One possible design uses a customer identifier as the partition key and an ordered value as the sort key.
PK SK
CUSTOMER#42 ORDER#2026-08-01T10:00:00Z#1001
CUSTOMER#42 ORDER#2026-08-03T14:30:00Z#1002
CUSTOMER#87 ORDER#2026-08-02T09:15:00Z#1003
A consistent sortable timestamp representation supports time-ordered access within the customer's item collection. The order identifier disambiguates matching timestamps.
This is an illustrative design, not a universal recommendation.
Find the missing question
If a support agent knows only the order identifier, the customer-based partition key does not directly answer that lookup. You may need another item shape or an index.
Write down the consistency and update implications of that extra access path. A convenient query is not free.
Watch skew
A design can have many distinct keys and still concentrate traffic on one hot customer. Inspect the busiest expected key, not only an average distribution.
Choosing a partition key needs both a data model and a workload model. Provider limits and adaptive behavior should be checked against current documentation for the deployed service.
Avoid relying on filters to make a read cheap
A filter applied after items are read is different from a key condition that narrows the read itself. Make that distinction when estimating capacity and latency.
Validate before deployment
Create representative item sizes and traffic patterns, estimate read and write costs, and measure the important operations. Document pagination and retry behavior. This guide creates no cloud resources; any future lab should specify its region, chargeable components, and cleanup steps.