1. DynamoDB Streams

DynamoDB Streams captures a time-ordered sequence of item-level modifications in a table and stores this information for up to 24 hours.

  1. Captures: INSERT, MODIFY, DELETE events
  2. Each record contains: the primary key, and optionally, the old/new item image
  3. Ordered per partition key (items with the same PK are ordered; across PKs, no guaranteed order)
  4. Retention: 24 hours
  5. Can trigger AWS Lambda functions (event source mapping)

Stream View Types

Common Stream Patterns

  1. React to changes: DynamoDB → Stream → Lambda → (send email, update search index, sync to another table)
  2. Cross-Region replication: DynamoDB Streams powers Global Tables
  3. Analytics pipeline: Stream → Kinesis Data Firehose → S3/Redshift
  4. Materialized views: maintain precomputed aggregations updated by stream events

2. DynamoDB Global Tables

  1. Fully managed, multi-Region, multi-active (read/write in any Region) replication
  2. Uses DynamoDB Streams under the hood to replicate changes
  3. Replication latency: typically <1 second
  4. All replicas can accept writes (no primary/secondary distinction)
  5. Last-writer-wins conflict resolution
  6. Must use On-Demand or have Auto Scaling enabled on all replicas
  7. Must enable DynamoDB Streams with NEW_AND_OLD_IMAGES

Use for: Globally distributed applications, disaster recovery, and low-latency access for global users.

3. DynamoDB Accelerator (DAX)

DAX is a fully managed, in-memory cache for DynamoDB. It delivers up to 10x performance improvement — from single-digit milliseconds to microseconds.

  1. In-memory cache sitting in front of DynamoDB
  2. Microsecond latency for cached reads
  3. Compatible with existing DynamoDB API calls (no code changes for reads)
  4. Write-through cache: writes go through DAX to DynamoDB
  5. TTL: configurable (default 5 minutes for items, 5 minutes for queries)
  6. Multi-AZ: up to 10 nodes (1 primary + up to 9 replicas)
  7. Runs in your VPC (must deploy EC2/Lambda in the same VPC)
  8. Does NOT support strongly consistent reads (only eventually consistent from cache)
DAX vs ElastiCache
DAX = purpose-built DynamoDB cache. No code changes. Sits between app and DynamoDB transparently. ElastiCache = general-purpose cache for any data source. Requires code changes. If the question is specifically about DynamoDB caching, the answer is DAX. If caching results from multiple sources or caching aggregated/computed data, the answer is ElastiCache.

4. DynamoDB Transactions

  1. ACID transactions across multiple items and tables
  2. Two operations: TransactWriteItems (up to 100 items) and TransactGetItems (up to 100 items)
  3. All-or-nothing: either all actions succeed, or all fail
  4. Costs 2x the normal RCU/WCU (because DynamoDB prepares + commits)
  5. Use for: financial transactions, order processing, any operation needing atomicity across items

5. DynamoDB TTL (Time to Live)

  1. Automatically delete expired items at no extra cost
  2. You specify an attribute containing the expiration timestamp (Unix epoch seconds)
  3. Items are typically deleted within 48 hours after expiration (not instant)
  4. Expired items appear in Streams as DELETE events
  5. No WCU consumed for TTL deletions
  6. Use for: session data, temporary tokens, event logs, shopping carts

6. DynamoDB Backups


On-Demand Backups

  1. Full backup at any time, retained until you delete it
  2. No performance impact during backup
  3. Can be restored to a new table (same or different Region)


Point-in-Time Recovery (PITR)

  1. Continuous backups of the last 35 days
  2. Restore to any second within the 35-day window
  3. Must be explicitly enabled (not on by default)
  4. Restores to a new table
  5. Uses DynamoDB Streams internally

7. DynamoDB Export to S3

  1. Export table data to S3 in JSON or Apache Ion format
  2. Does NOT consume RCU (uses PITR data)
  3. Enables querying with Athena, data lake integration, and archival
  4. PITR must be enabled
  5. Export is a point-in-time snapshot (not real-time)

8. DynamoDB Import from S3

  1. Import data from S3 into a NEW DynamoDB table
  2. Supported formats: CSV, DynamoDB JSON, Amazon Ion
  3. Does NOT consume WCU (import goes directly to storage)
  4. Creates a new table (cannot import into an existing table)

9. DynamoDB PartiQL

  1. SQL-compatible query language for DynamoDB
  2. Use familiar SELECT, INSERT, UPDATE, and DELETE syntax
  3. Runs in Console, CLI, SDK, and NoSQL Workbench
  4. Under the hood, it still uses DynamoDB’s Query/Scan/PutItem APIs
  5. Does NOT change DynamoDB’s underlying behavior or limitations
Exam Tip
DynamoDB Advanced: Streams = 24-hour event log (INSERT/MODIFY/DELETE). Global Tables = multi-Region, multi-active, <1s replication. DAX = microsecond DynamoDB cache, no code changes, eventually consistent only. Transactions = 2x cost, ACID. TTL = auto-delete expired items, free. PITR = 35 days continuous, must enable. Export to S3 = no RCU (uses PITR). "Improve DynamoDB read latency" = DAX. "Global low-latency writes" = Global Tables.