DynamoDB NoSQL

1Primary keys and partition design

Every DynamoDB item is addressed by a primary key. A simple key is a partition key alone; a composite key adds a sort key so multiple items can share one partition key and be ordered or ranged within it. The partition key is not just an identifier — it is the hash input that decides which physical partition stores the item, so its cardinality and distribution shape throughput.

A low-cardinality partition key — status=active on a table with millions of rows — concentrates writes and reads on one partition and creates a hot partition that throttles even when the table's total capacity looks generous. High-cardinality keys (userId, orderId, a composite of tenantId plus shard suffix) spread load. Concatenating attributes is a common exam trick to turn a skewed attribute into many distinct partition keys.

Figure. Partition key chooses the shard; sort key orders items inside that partition for Query ranges.

How keys drive access

1. Name the partition keyThis is the attribute you must supply in every efficient Query — it alone determines which partition DynamoDB reads.
2. Add a sort key when neededComposite keys let you store many items under one partition key and query a range (time-ordered sessions per user, line items per order).
3. Check cardinalityIf one value could dominate traffic, redesign the partition key or add a random suffix to spread writes.

2Provisioned versus On-Demand capacity

Provisioned mode sets explicit read and write capacity units (RCU/WCU) with optional Application Auto Scaling to track load. You pay for the capacity you reserve whether or not every unit is used, which rewards steady, forecastable traffic.

On-Demand mode bills per request and scales without you pre-sizing RCU/WCU. Instant headroom covers bursts near a recent peak (classically about double that peak); larger brand-new peaks keep scaling as DynamoDB adds capacity. That still makes On-Demand the default exam answer for spiky or unknown workloads (a game launch, a flash sale) — including stems that quote a 10× launch multiplier you could not have provisioned in advance. You can switch between modes once every 24 hours, so launching On-Demand and moving to Provisioned with auto scaling after traffic stabilises is a valid cost-optimisation path.

Figure. Provisioned caps and prices reserved throughput; on-demand bills per request with automatic scaling.

Which mode the stem wants

1. Traffic unknown or spiky?On-Demand — no capacity planning, pay per request; do not reject it because a stem says 10×.
2. Steady, predictable load?Provisioned with auto scaling — cheaper at sustained utilisation when you can forecast RCU/WCU.
3. After launch stabilisesReassess: switch to Provisioned (once per 24 h) if the peak is now predictable.

3RCU and WCU sizing

Read capacity is measured in RCUs. One RCU supports one strongly consistent read per second for an item up to 4 KB, or two eventually consistent reads per second for items up to 4 KB each. Write capacity is simpler: one WCU is one write per second for an item up to 1 KB. DynamoDB always rounds up to the next 4 KB boundary for reads and the next 1 KB boundary for writes.

Item size matters twice: larger items consume more units per access, and a single item cannot exceed 400 KB including all attributes. Exam stems often pair a stated item size with a read consistency choice — compute RCUs with the 4 KB chunk rule, then halve (rounding up) for eventually consistent reads.

Figure. RCU/WCU round item size to 4KB/1KB blocks — oversized items multiply write units fast.

How to size a request

1. Measure item sizeSum all attribute bytes; confirm it is under the 400 KB per-item limit.
2. Reads: divide by 4 KB, round upThat count is RCUs for one strongly consistent read per second.
3. Eventually consistent readsHalf the strong RCU count, rounded up — two eventual reads of 4 KB each share one RCU.
4. Writes: divide by 1 KB, round upThat count is WCUs for one write per second.

4Query, Scan, and TTL

Query requires a partition key (and optionally a sort-key condition) and reads only the matching item collection — this is the efficient access path every well-modelled table should use. Scan reads every item in the table (or index) and consumes capacity proportional to table size, regardless of how few rows match a filter. The exam trap is reaching for Scan when the fix is a better key or a GSI.

Time to Live (TTL) lets DynamoDB delete expired items automatically based on a numeric epoch attribute (expiresAt). TTL deletes are free and need no application cron — enable TTL on the attribute and DynamoDB removes stale rows in the background.

Figure. Query names a partition key and optional sort-key condition, so it touches one item collection. Scan walks the whole table (or index) and burns capacity proportional to size. TTL deletes expire items without changing that access choice.

Modelling a sessions table

1. Partition + sort for the main pathuserId as partition key and sessionTimestamp as sort key — Query returns a user's sessions in time order.
2. Enable TTLSet expiresAt as the TTL attribute so stale sessions delete automatically at no write cost.
3. Lookup by sessionId aloneThat is a different partition key — add a GSI on sessionId (see the GSI concept).
4. Never Scan for routine lookupsScan is the fallback when no key or index supports the access pattern.

5Global versus Local Secondary Index

A secondary index lets you query on attributes beyond the table's primary key. A Global Secondary Index (GSI) has its own partition key and optional sort key — you can query any attribute pattern you project, provision separate capacity, and add or drop GSIs after the table exists. A Local Secondary Index (LSI) keeps the table's partition key but swaps in an alternate sort key; it must be defined at table creation, shares the table's throughput, and all items with the same partition key share a 10 GB item-collection limit. If the exam stem needs to look up rows by an attribute that is not the primary key, the answer is almost always a GSI, not an LSI.

Figure. An LSI must reuse the table's partition key and can only be created with the table. A GSI may choose a new partition key and can be added later — that is the fork the comparison table encodes.

Which index the stem wants

1. Same partition key, new sort order?LSI — only if the table was created with that LSI and you stay within the 10 GB per-partition-key collection.
2. Different partition key or post-launch need?GSI — own key schema, own capacity, add anytime.
3. Query a non-key attributeGSI with that attribute as the index key (or projected for filter). Scan is the expensive fallback.

6DynamoDB Streams

DynamoDB Streams captures item-level change events — insert, modify, remove — and retains them for 24 hours. Each stream record includes the keys and, depending on stream view type, the new image, old image, or both. Streams are ordered per partition key, so related changes on the same key arrive in sequence.

The standard exam pattern is Streams plus Lambda: enable a stream on the table, attach a Lambda event source mapping, and react to changes without polling. Use this for replication to another store, aggregating counters, sending notifications, or any event-driven workflow triggered by writes.

Figure. Item changes flow table → Stream (24 h retention) → Lambda via an event source mapping.

Event-driven processing path

1. Enable the streamTurn on DynamoDB Streams on the table and pick the view type (keys only, new image, old image, or both).
2. Attach LambdaCreate an event source mapping from the stream to a Lambda function — no polling loop required.
3. Process within 24 hoursRecords expire after 24 h; design idempotent handlers in case of retries.

7DAX read acceleration

DynamoDB Accelerator (DAX) is an in-memory cache cluster in front of DynamoDB tables. It delivers microsecond read latency for read-heavy workloads where the same items are fetched repeatedly — leaderboards, user profiles, session lookups under load.

DAX is not a replacement for proper key design or GSIs; it accelerates reads that already hit the table efficiently. Writes still go to DynamoDB; DAX handles cache invalidation. Add DAX when the stem emphasises read latency at scale, not when the problem is a missing access pattern.

Figure. DAX is a write-through cache in front of DynamoDB for microsecond reads of hot keys.

When DAX fits

1. Read-heavy and repetitive?Same keys fetched many times per second — leaderboard scores, hot product pages.
2. Microsecond latency required?DAX sits closer than repeated DynamoDB reads even at single-digit millisecond table latency.
3. Access pattern already correct?Fix keys and indexes first; DAX caches successful reads, it does not invent a query path.