1.3 Amazon DynamoDB
Key Takeaways
- The partition key determines data distribution (choose high cardinality to avoid hot partitions); an optional sort key orders items within a partition and enables range queries.
- On-demand mode scales automatically and bills per request (RRU/WRU); provisioned mode sets RCU/WCU you pay for and supports auto scaling and reserved capacity for steady traffic.
- A GSI has its own partition/sort key and capacity, is eventually consistent, and is addable anytime; an LSI shares the table's partition key, supports strong reads, and must be created with the table.
- Query reads items by partition key efficiently; Scan reads the entire table/index then filters, so a filter expression never reduces the read capacity consumed.
- Optimistic locking uses a version attribute with a conditional write to prevent lost updates; DAX is an in-memory cache delivering microsecond DynamoDB reads.
Tables, Items, Attributes, and Keys
Amazon DynamoDB stores items (rows) made of attributes (fields) in tables. The primary key is either a partition key alone or a composite partition key + sort key. The partition key is hashed to spread data across physical partitions, so pick a high-cardinality, evenly accessed value — userId or orderId, not status or country — to avoid hot partitions and throttling. A crucial exam point: throwing more capacity at a poorly chosen key does not fix throttling, because a single partition is still limited (roughly 3,000 RCU and 1,000 WCU per partition).
Read and Write Capacity Units
- One RCU = one strongly consistent read of up to 4 KB per second (or two eventually consistent reads of 4 KB).
- One WCU = one write of up to 1 KB per second.
- A 10 KB strongly consistent read consumes 3 RCU (round 10/4 up to 3); a 1.5 KB write consumes 2 WCU.
Capacity Modes
| Mode | Best For | Billing |
|---|---|---|
| On-demand | Unpredictable/spiky or new workloads | Per request (RRU/WRU), zero capacity planning |
| Provisioned | Steady, predictable traffic | Set RCU/WCU; add auto scaling and reserved capacity for lower cost |
A workload that throttles unexpectedly during spikes is the classic cue to switch from provisioned to on-demand, which absorbs sudden bursts without pre-planned capacity.
GSI vs LSI
- Global Secondary Index (GSI): its own partition and sort key, its own provisioned/on-demand capacity, eventually consistent reads, and can be added or removed anytime. Use a GSI to support a brand-new access pattern. If the GSI's writes are throttled, writes to the base table are throttled too.
- Local Secondary Index (LSI): shares the table's partition key but defines an alternate sort key, supports strongly consistent reads, shares the table's capacity, and must be created at table creation (you cannot add one later). LSIs also impose a 10 GB per-partition-key limit.
Query vs Scan
Query retrieves items by a specific partition key (optionally narrowed by a sort-key condition such as begins_with or a range) and reads only matching items — efficient and capacity-friendly. Scan reads every item in the table or index and then applies a filter, consuming capacity proportional to the data scanned. The most-tested subtlety: a filter expression runs after the read, so it discards items but never reduces the read capacity consumed. Prefer Query (or a GSI) and treat Scan as a last resort; use parallel scans only for full-table batch jobs.
Streams, TTL, Transactions, and Locking
- DynamoDB Streams capture an ordered, time-ordered log of item-level changes for 24 hours, with
StreamViewTypeoptions of KEYS_ONLY, NEW_IMAGE, OLD_IMAGE, or NEW_AND_OLD_IMAGES — process with Lambda for change-data-capture, aggregation, or replication. - TTL (Time To Live) auto-deletes expired items based on an epoch-timestamp attribute, eventually and at no extra write cost — ideal for sessions and ephemeral records.
- Transactions (
TransactWriteItems/TransactGetItems) group up to 100 actions (up to 4 MB) in an all-or-nothing, ACID operation across one or more tables. - Optimistic locking adds a
versionattribute and a conditional write that succeeds only if the stored version still matches what you read, preventing lost updates without holding a lock.
DAX and Error Handling
DynamoDB Accelerator (DAX) is a managed, write-through in-memory cache delivering microsecond reads for read-heavy, eventually consistent workloads with minimal code change — it does not help write-heavy or strongly consistent patterns. When a request exceeds capacity, DynamoDB returns ProvisionedThroughputExceededException (HTTP 400); the SDK retries it with exponential backoff. For batch operations, always inspect and retry UnprocessedItems (BatchWriteItem) or UnprocessedKeys (BatchGetItem).
Single-Table Design and Expressions
DynamoDB rewards single-table design, where multiple entity types share one table and overloaded keys (a generic PK/SK) serve many access patterns via GSIs. You write access patterns first, then model keys to satisfy them — the opposite of relational normalization. Expression attribute names (#n) sidestep reserved words, and expression attribute values (:v) parameterize conditions. UpdateItem supports atomic counters with ADD and SET so two clients can both increment a value without reading first. ProjectionExpression returns only needed attributes to save capacity, and ReturnValues can echo the old or new item.
Global Tables, Backups, and Traps
Global Tables give multi-Region, active-active replication with last-writer-wins conflict resolution for low-latency global apps and disaster recovery. Point-in-time recovery (PITR) allows restore to any second in the last 35 days, and on-demand backups are instantaneous.
Common exam traps: assuming a Scan with a filter saves capacity (it does not); choosing an LSI for a brand-new partition key (impossible — LSIs share the table's partition key and must exist at creation); picking a low-cardinality partition key like status and then blaming throttling on capacity; and forgetting that GSIs are eventually consistent, so a read immediately after a write may not yet reflect the change. Another subtle trap is exceeding the 400 KB maximum item size, which forces you to split large attributes or offload them to S3 and store only a reference in the item.
Finally, when a transaction conflicts with a concurrent write, DynamoDB returns a TransactionConflictException, and the SDK retries it with backoff — design the workflow to tolerate that retry rather than treating it as a hard failure.
An application frequently retrieves orders by customerId (the partition key) and now also needs to look up orders by orderStatus, which is not part of the key. Reads on the new pattern tolerate slight staleness. What should you create?
A developer reports that adding a filter expression to a Scan did not reduce the consumed read capacity units. Why?
Two clients read the same item and both try to update it. You must prevent the second write from silently overwriting the first without using an external lock service. What is the standard DynamoDB approach?