DynamoDB Core Concepts

Tables, items, partition keys, and sort keys — the NoSQL engine behind high-write workloads.

Advanced11 min read

Read these first

Elasticsearch Production Ops

Why this matters

VaultCommerce's high-write order-events service outgrew Postgres connection limits — DynamoDB scales partitions horizontally when keys are well distributed.
You cannot ad-hoc query arbitrary attributes; the primary key (and indexes) define every read path upfront.
Single-digit millisecond latency comes from predictable key lookups, not from scanning tables.

Tables, items, and attributes

Java

{
  "PK": "USER#42",
  "SK": "ORDER#2026-0042",
  "customerName": "Alice Chen",
  "totalAmount": 129.99,
  "status": "SHIPPED",
  "lineItems": [
    { "sku": "SKU-8842", "qty": 1, "price": 89.00 }
  ]
}

Building blocks

Table — collection of items; no fixed schema beyond the key definition.
Item — one record, up to 400 KB including attribute names and values.
Attribute — name-value pair; types include string, number, boolean, list, map, set.
Primary key — partition key alone, or partition + sort key (composite).

Partition and sort keys

Partition key: USER#42Routes to shard

Items in partition

ORDER#2026-001Sort key

ORDER#2026-002Sort key

PROFILESort key

Partition key routes to a shard. Sort key orders items within that partition.

The partition key USER#42 lands on one shard. Sort keys ORDER#... and PROFILE coexist in the same partition, queryable in sort order.

Java

aws dynamodb create-table \
  --table-name VaultCommerceOrders \
  --attribute-definitions \
    AttributeName=PK,AttributeType=S \
    AttributeName=SK,AttributeType=S \
  --key-schema \
    AttributeName=PK,KeyType=HASH \
    AttributeName=SK,KeyType=RANGE \
  --billing-mode PAY_PER_REQUEST

When DynamoDB fits VaultCommerce

VaultCommerce uses DynamoDB for session-less, high-churn workloads: clickstream aggregates, idempotency tokens, and per-user order timelines keyed by USER#id. Product catalog and financial reporting stay in Postgres where joins and ACID matter.

Consistency model

Reads default to eventually consistent (half RCU cost). Strongly consistent reads return the latest write but cost double RCUs and only apply to the same partition key region.

Quick recall

Everything you need if you only revisit this box.

Items are JSON-like documents keyed by partition key (+ optional sort key).
Partition key determines shard placement; sort key enables range queries within shard.
400 KB item limit — store blobs in S3, references in DynamoDB.
Schema-flexible attributes, but access patterns must be designed upfront.
VaultCommerce uses composite keys like USER#42 + ORDER#2026-0042.
Eventually consistent reads are cheaper; strong reads when you must not see stale data.

Test yourself

Answer these before moving on — recall is what makes it stick.