⭐⭐⭐⭐ High Priority

🗄️ DynamoDB Optimization

DynamoDB is AWS's fully managed NoSQL database. For optimization in Domain 4, the key topic is DynamoDB Streams — which captures every change to your table in real time and enables powerful event-driven patterns.

🔑 Covers: DynamoDB Streams · Event-Driven Processing · Data Consistency · Change Capture

🌊 DynamoDB Streams — Capture Every Change

DynamoDB Streams is a feature that captures a time-ordered sequence of every item-level modification (insert, update, delete) that happens in a DynamoDB table. Each change creates a "stream record" that describes what changed.

DynamoDB Streams
A time-ordered log of every write operation on your DynamoDB table. Like a "transaction log" for your database. Stream records contain information about what was changed, and optionally the before/after values of the item. Stream records are retained for 24 hours and consumed by downstream processors (usually Lambda).
DynamoDB Streams — How Data Flows
📝App writes to DynamoDBPutItem, UpdateItem, DeleteItem
🌊DynamoDB StreamsRecords every change (24hr retention)
λLambda TriggerProcess each change in real-time

📋 Stream Record View Types — What Data is Captured

View TypeWhat's in the stream recordUse when
KEYS_ONLYOnly the key attributes of the modified itemYou just need to know what changed, not the values
NEW_IMAGEThe entire item as it appears AFTER the modificationYou want the current state of changed items
OLD_IMAGEThe entire item as it appeared BEFORE the modificationYou want to know what was deleted/overwritten
NEW_AND_OLD_IMAGESBoth the old and new versions of the itemYou want to compute what changed (diff the before/after)

🎯 Use Cases for DynamoDB Streams

📧 Downstream Notifications

When a new order is added to DynamoDB → Stream → Lambda → Send confirmation email via SES. Lambda is triggered automatically on every new item.

🔍 Search Index Sync

Keep an OpenSearch index in sync with DynamoDB. Every change to DynamoDB → Stream → Lambda → Update OpenSearch. Users can then search DynamoDB data using full-text search.

📊 Aggregation and Analytics

Compute aggregates as data changes. Example: when items are inserted, update a running total. Maintains a separate "summary table" that's always up to date.

🔄 Cross-Region Replication

Stream changes → Lambda → Write to DynamoDB in another region. Keep two tables in sync. (Today, Global Tables do this automatically — but streams enable custom replication logic.)

🎯 Critical Exam Pattern
Scenario: "Events from a DynamoDB table are being missed or users report that notifications are not always sent when table items are updated."
Answer: Enable DynamoDB Streams + Lambda trigger. Streams capture EVERY modification reliably and trigger Lambda for each change. The trigger ensures zero missed events (unlike polling).

"Missing updates/events" from DynamoDB → the answer is DynamoDB Streams.

DynamoDB DAX — In-Memory Caching

DynamoDB Accelerator (DAX)
A fully managed, in-memory cache specifically built for DynamoDB. DAX sits in front of DynamoDB and caches GetItem and Query responses. Without DAX, reads take milliseconds. With DAX, reads take microseconds (100-1000x faster). DAX is DynamoDB-specific — you use the DAX SDK instead of DynamoDB SDK, but the API is compatible.

🗄️ DynamoDB Direct (Reads)

  • Single-digit milliseconds per read
  • Scales to millions of requests/sec but has cost at scale
  • Every read hits the DynamoDB storage nodes

⚡ DynamoDB + DAX (Reads)

  • Microseconds per cached read
  • Reduces DynamoDB read traffic by 90%+
  • Ideal for read-heavy, repetitive access patterns (gaming leaderboards, product catalog)

Data Consistency with Streams

DynamoDB Streams provides at-least-once delivery — each stream record is delivered to consumers at least once. Your Lambda function must be idempotent (handle the same record twice without side effects).

Idempotent
An operation that produces the same result regardless of how many times it's called with the same input. Example: setting a value to 5 is idempotent (calling it twice still results in 5). Incrementing by 1 is NOT idempotent (calling it twice results in +2). Your Lambda handlers that process stream records should be idempotent to handle duplicate delivery safely.