Amazon Web Services services
21 / 24
Amazon Web Services

DynamoDB Data Modelling — Keys, Indexes & Capacity

Design partition keys and indexes for access patterns, and avoid the hot partition that caps throughput.

DynamoDB is fast only if the key design matches the queries. This is the most-asked AWS database topic.

A filing room where the partition key is the cabinet and the sort key is the order of folders inside it. Put everything in one cabinet and there is a queue at its door, however many cabinets the room has.

Key Concepts

1
    partition key (PK)   decides which partition the item lives on
    sort key (SK)        orders items within that partition
2
    PK alone      -> GetItem, one item
    PK + SK range -> Query, many items, already sorted
    neither       -> Scan, reads the whole table. Avoid.
3
Design from the access patterns, not from the entities. Relational modelling then adding indexes is the mistake. List the queries first, then build keys that answer them.
4
A hot partition is the classic failure.
    PK = "ORDERS"           everything on one partition, capped
    PK = customerId         spread across many, each query local
    PK = date               every write today hits one partition
5
Throughput is per partition, so a low-cardinality key means the table is throttled while most capacity sits idle.
6
Composite sort keys answer range queries.
    PK = CUSTOMER#123
    SK = ORDER#2026-03-15#A91
7
    Query PK = CUSTOMER#123 AND begins_with(SK, "ORDER#2026-03")
      -> that customer's March orders, sorted, one request
8
GSI versus LSI.
    GSI   different PK and SK, added any time, its own capacity,
          eventually consistent. Almost always the right choice.
    LSI   same PK, different SK, must be created with the table,
          shares capacity, allows strong consistency.
9
A GSI is a copy of the table, so projecting every attribute doubles storage and write cost. Project only what the query needs.
10
Capacity modes.
    on-demand     pay per request, no planning, more per request.
                  Spiky or unknown traffic.
    provisioned   cheaper at steady volume, with auto-scaling.
11
Single-table design puts several entity types in one table with a generic PK/SK, so one query can return a customer and their orders together. Powerful, and harder to read — be ready to justify it rather than apply it reflexively.
12
DynamoDB Streams emit every change, which is how you trigger Lambda, maintain aggregates or replicate.
13
What the interviewer is probing.1. "How do you choose a partition key?" Probing: the central skill. Stalls: "Something unique." Moves up: high cardinality, evenly accessed, and present in most queries — because throughput is per partition, a low-cardinality key throttles while capacity sits idle.
14
2. "Your table is throttling but you are well under provisioned capacity. Why?" Probing: the hot partition. Stalls: "The limit is wrong." Moves up: capacity is divided across partitions, so one hot key saturates its own share while the rest go unused.
15
3. "When would you use a GSI, and what does it cost?" Probing: the index trade. Stalls: "Whenever you need another query." Moves up: when you need a different access pattern; it is a copy of the data, so projecting everything doubles storage and write cost, and it is eventually consistent.
16
4. "Why is Scan a design smell?" Probing: access patterns. Stalls: "It is just slow." *Moves up:* it reads the whole table, which means the key design does not answer the question being asked.
Use cases:dynamodbpartition-keygsisingle-tablehot-partition