The key design begins with access patterns#
DynamoDB is useful when requests can be expressed through well-designed partition and sort keys and the team values a managed distributed operating model. It is not “NoSQL for big scale.” Write the important reads and writes first; those patterns shape keys and secondary indexes.
Mental model: key shape drives distribution and lookup#
Recent orders for one customer
PK = CUSTOMER#123
SK = ORDER#2026-08-14T14:05:00Z
Query one customer partition ordered by time.This is one possible design, not a universal single-table recipe. A good partition key both supports the request and spreads traffic. A popular event or tenant can still concentrate demand.
Secondary indexes buy access patterns with write and consistency cost#
A global secondary index can use different partition and sort keys and is maintained asynchronously from the base table. Its reads are eventually consistent. A local secondary index shares the base partition key and can support strongly consistent reads, but has different lifecycle and storage constraints. Interview depth is the propagation, partitioning, and write-amplification tradeoff - not memorized limits.
DynamoDB is not simply “eventually consistent”#
Table and local-secondary-index reads can request eventual or strong consistency. Global-secondary-index and stream reads are eventually consistent. Global tables also have mode-specific behavior, so state the exact resource and region boundary before promising what a user observes.
Hot partitions are a key-design failure, not only a capacity problem#
PK = EVENT#POPULAR_CONCERT routes one event's traffic together. Depending on required reads and writes, consider time or hash buckets, a different aggregate model, caching, or separating contested inventory from read-heavy event data. Bucketing adds fan-out and aggregation work, so do not salt a key automatically.
DynamoDB vs PostgreSQL#
| PostgreSQL tendency | DynamoDB tendency |
|---|---|
| Relations, joins, constraints, flexible transactions and queries | Predictable key-oriented access and managed partitioned operations |
| Schema can support evolving ad hoc access | Access patterns shape key and index design up front |
| Scale through primary/replica and later sharding choices | Distribution is part of the service model, but hot keys remain possible |
- Choosing DynamoDB because “NoSQL scales.”
- Designing the table before listing access patterns.
- Calling every read eventually consistent.
- Assuming GSIs update synchronously.
- Ignoring hot tenants, items, and secondary-index keys.
- Using scans as the primary serving plan.
Use these prompts to extend the design. The useful answer is a reasoned change, not a memorized sentence.
- Which requests does this key shape serve?
- Can one partition key become hot?
- Which read needs strong consistency?
- What does a stale GSI result do to the product?
- Why not use PostgreSQL?
Related practice problems
Use the manifest-backed prompts below to apply this lesson in a complete design.
- DynamoDB read consistencyAWS Documentation
- DynamoDB global secondary indexesAWS Documentation
- DynamoDB read and write operationsAWS Documentation