DynamoDB

DynamoDB is a managed key-value/document database whose efficient access depends on known partition and sort key patterns. A schema should be derived from queries, item-size and throughput constraints, and transaction needs. It is not a relational database with arbitrary joins hidden behind a different syntax.

The mechanism at a glance

Figure — Application query → Partition + sort key (known access pattern); Partition + sort key → Base table (bounded read/write); Partition + sort key → Secondary index (alternate lookup); Application query → Conditional transaction (atomic condition); Base table → Throttling metrics (hot-key measurement)

The numbered components identify responsibilities. Follow the labeled arrows rather than treating the numbers as a global execution order. The scenario later in this lesson shows one concrete sequence.

Step-by-step reasoning

1. 1 · Frame

List read/write patterns with frequency and required consistency. Design partition keys that distribute traffic and sort keys that support bounded range queries. A tenant-only key may create a hot partition for a very large tenant; adding a time bucket or shard suffix spreads work but makes cross-bucket reads and writes more complex.

2. 2 · Model

Single-table designs can place multiple entity types under partition/sort keys and use prefixes for access patterns. Secondary indexes provide alternate lookups with their own projection and propagation properties. Conditional writes enforce per-item invariants; transactions group supported items but add limits and cost. Keep item sizes and request units within service constraints for the selected deployment.

3. 3 · Scale

Use strongly consistent reads only where the access path and operation require them and support that mode; otherwise define eventual freshness. Global tables and cross-region behavior need explicit conflict and replication expectations. Hot keys should be measured by partition activity and throttling. Use adaptive capacity thoughtfully, not as a substitute for a skew-aware key design.

4. 4 · Recover

Retries after a timeout may have written the item. Conditional expressions and transaction request tokens, where applicable, can make retries safer within the documented semantics. Handle throttling with backoff and jitter, and do not immediately fan out more workers. Reconcile multi-item workflows whose external side effects are outside a DynamoDB transaction.

Contracts and state

The following sketch makes the decision boundary concrete. Field names and capacity assumptions are illustrative; adapt them to the stated product contract.

PK = TENANT#42, SK = ORDER#2026-10-08#o17
GSI1PK = USER#u9, GSI1SK = ORDER#created#o17
Conditional update: version = expected_version
Transaction: bounded set of related item operations
Hot-tenant alternative: shard suffix + explicit query fan-out

Worked example

An orders screen asks for one tenant’s 50 newest orders. A tenant/order partition with a sortable timestamp supports a bounded query. If one tenant becomes exceptionally hot, shard its key across a small number of buckets and query each bucket, then merge 50 candidates. The extra read fan-out is an explicit cost of distributing writes.

Failure walkthrough

A conditional update times out. Repeating it without a stable request identity may increment a balance twice. Use a condition/version or idempotency item in the same supported transaction, then resolve ambiguous outcomes by reading the authoritative item. A global secondary index may lag; do not use its result as the sole authority for a uniqueness invariant.

Figure — Tenant traffic grows hot → Add bounded key buckets → Write to stable shard → Query each bucket → Merge ordered page

Decisions and trade-offs

Check your understanding

How would you make a hot tenant’s recent-order query scale, and what query cost does that introduce?

Primary documentation

Read the first-party engineering account or official technical reference. Company engineering posts describe the scope and date of that publication; the interview reconstruction and scenarios here are original teaching examples.

Continue the connection

Study Data Modeling and explain which guarantee from this lesson carries into that topic.

Model the query and conditional write together

Choose partition and sort keys from access patterns. An item collection for one account can colocate profile, orders and state under one partition key with distinct sort-key prefixes. This can simplify queries but requires deliberate size and traffic distribution. A scan is not a substitute for a missing access pattern at scale.

Conditional expressions enforce version checks or absence at the write boundary. Transactions support coordinated item operations within their documented limits, while secondary indexes provide additional access paths with their own consistency and capacity behavior. Do not assume a global secondary index is an immediately current authority for uniqueness.

TTL is asynchronous cleanup, not an exact lease-expiry scheduler. Read the expiry value when deciding whether ownership is still valid. Hot partition keys remain hot under on-demand capacity; adaptive behavior does not remove every per-key or partition constraint. Store stable request IDs and compare-and-set generations for retryable work.

Figure — A decision worksheet for DynamoDB: read the mechanism and its guarantee together.

Operational sketch

PK = TENANT#42; SK = JOB#17
state=running; generation=8; expires_at=...
conditional update: generation = :expected
unique operation item: attribute_not_exists(PK)
query by key; avoid full-table scan

A tempting mistake

An expired item can still exist until cleanup runs. Treat expiration as business data during conditional decisions, not as proof that the database has removed the item.

Transfer exercise

Can a GSI lookup followed by PutItem guarantee uniqueness?