Amazon DynamoDB¶

Core trade-off:
  RDS:       SQL + ACID + complex queries  →  structured, relational data
  DynamoDB:  Flexible schema + speed       →  unstructured, high-volume, low latency

Table
 └── Item (one record — equivalent to a row)
      ├── Attribute: { "user_id": "123" }      ← Partition Key (required)
      ├── Attribute: { "timestamp": "2026-…" } ← Sort Key (optional)
      ├── Attribute: { "name": "Ibtisam" }
      └── Attribute: { "tags": ["aws","k8s"] } ← can differ per item (schema-less)

Table: Users
  PK: user_id

Items:
  { "user_id": "u-001", "name": "Ibtisam" }
  { "user_id": "u-002", "name": "Ali" }

Query: GetItem(user_id="u-001") → exact match only

Table: Orders
  PK: user_id (partition key)
  SK: order_date (sort key)

Items in same partition (same user):
  { "user_id": "u-001", "order_date": "2026-01-01", "amount": 99  }
  { "user_id": "u-001", "order_date": "2026-03-15", "amount": 150 }
  { "user_id": "u-001", "order_date": "2026-04-01", "amount": 200 }

Query: all orders for user u-001 in 2026
  → KeyConditionExpression: user_id = "u-001" AND order_date BETWEEN "2026-01-01" AND "2026-12-31"

DynamoDB hashes partition key → determines which physical partition stores the item
Each partition: max 10 GB data, max 3,000 RCUs, max 1,000 WCUs

Table grows → DynamoDB splits partitions automatically (no downtime)

Bad design: status as partition key
  "PENDING":  10,000 writes/sec  → all hit one partition → throttled ❌
  "COMPLETE": 100 writes/sec
  "FAILED":   10 writes/sec

Good design: user_id or order_id as partition key (high cardinality)
  user-001: 5 writes/sec
  user-002: 3 writes/sec
  user-003: 8 writes/sec
  → evenly distributed across partitions ✅

{
  "user_id":    { "S": "u-001" },
  "age":        { "N": "25" },
  "active":     { "BOOL": true },
  "tags":       { "SS": ["aws", "k8s", "devops"] },
  "address": {
    "M": {
      "city":   { "S": "Rawalpindi" },
      "zip":    { "S": "46000" }
    }
  },
  "scores":     { "L": [{ "N": "95" }, { "N": "87" }] }
}

No capacity planning — DynamoDB scales instantly
Pay: per actual read/write request
Use when: unpredictable traffic, new applications, spiky workloads
Cost: ~2.5× more expensive per request than provisioned

You set: RCUs (read capacity units) per second
         WCUs (write capacity units) per second
Pay: per provisioned RCU/WCU per hour regardless of usage
Use when: predictable, steady workloads
Add: Auto Scaling to adjust provisioned capacity based on utilization

1 WCU = 1 write per second for item up to 1 KB

Formula:
  WCU = writes_per_second × CEIL(item_size_KB / 1 KB)

Examples:
  Item = 0.5 KB, 100 writes/sec  → 100 × CEIL(0.5) = 100 × 1 = 100 WCU
  Item = 1.5 KB, 100 writes/sec  → 100 × CEIL(1.5) = 100 × 2 = 200 WCU
  Item = 3 KB,   50 writes/sec   → 50  × CEIL(3)   = 50  × 3 = 150 WCU

1 RCU = 1 strongly consistent read per second for item up to 4 KB
       OR
0.5 RCU = 1 eventually consistent read per second for item up to 4 KB

Formula:
  RCU (strong)    = reads_per_second × CEIL(item_size_KB / 4 KB)
  RCU (eventual)  = reads_per_second × CEIL(item_size_KB / 4 KB) × 0.5

Examples:
  Item = 4 KB,  100 strongly consistent reads/sec  → 100 × 1   = 100 RCU
  Item = 4 KB,  100 eventually consistent reads/sec → 100 × 0.5 = 50 RCU
  Item = 6 KB,  50 strongly consistent reads/sec   → 50  × CEIL(6/4) = 50 × 2 = 100 RCU
  Item = 10 KB, 80 eventually consistent reads/sec  → 80  × CEIL(10/4) × 0.5 = 80 × 3 × 0.5 = 120 RCU

Default: Eventually Consistent (faster, costs 0.5 RCU)
  → Read may return data that is milliseconds behind
  → Use for: high-throughput read workloads, leaderboards, caches

Strongly Consistent (slower, costs 1 RCU)
  → Always returns latest committed data
  → Use for: financial balances, inventory, any "must be latest" data
  → Add --consistent-read flag in API call

Not available for:
  → Global Tables (always eventually consistent cross-region)
  → GSI reads (always eventually consistent)

Same partition key as base table, DIFFERENT sort key
Must be created AT TABLE CREATION — cannot add later
Max: 5 LSIs per table
Storage: shares table storage
Reads: supports strongly consistent reads

Table: Orders (PK: user_id, SK: order_date)
LSI: Orders-by-amount (PK: user_id, SK: amount)

Query: "get all orders for user u-001 sorted by amount"
  → Use LSI (same partition key = user_id)

DIFFERENT partition key + optional different sort key
Can be added/deleted at ANY TIME (even after table creation)
Max: 20 GSIs per table
Storage: separate storage (own RCU/WCU)
Reads: eventually consistent only

Table: Orders (PK: user_id, SK: order_date)
GSI: Orders-by-status (PK: status, SK: order_date)

Query: "get all PENDING orders sorted by date"
  → Cannot do on base table (status not a key)
  → Use GSI (new partition = status) ✅

Scan is dangerous:
  Table: 50 million items × 400 KB max = up to 20 TB scan
  → Consumes massive RCUs
  → Can throttle production traffic
  → Use FilterExpression to reduce returned data (but scan still reads ALL items)

Design principle:
  "Design your table around your access patterns — never design and then query"
  → Know your queries first → then design PK/SK/GSI to serve those queries

# All-or-nothing: both writes succeed or both fail
dynamodb.transact_write_items(
    TransactItems=[
        {
            'Put': {
                'TableName': 'Orders',
                'Item': {'order_id': {'S': 'o-123'}, 'status': {'S': 'CONFIRMED'}}
            }
        },
        {
            'Update': {
                'TableName': 'Inventory',
                'Key': {'product_id': {'S': 'p-456'}},
                'UpdateExpression': 'SET stock = stock - :val',
                'ConditionExpression': 'stock >= :val',
                'ExpressionAttributeValues': {':val': {'N': '1'}}
            }
        }
    ]
)
# If inventory check fails (stock < 1) → entire transaction rolls back

Insert/Update/Delete item
  → Event written to Stream (retention: 24 hours)
  → Lambda trigger reads Stream
  → Process event: audit log, replication, search index update, notifications

Stream record contains:
  KEYS_ONLY:          Only key attributes
  NEW_IMAGE:          New item state after change
  OLD_IMAGE:          Old item state before change
  NEW_AND_OLD_IMAGES: Both states (most common — enables delta comparison)

Without DAX:
  App → DynamoDB API → 1–10ms latency per read

With DAX:
  App → DAX Cluster (cache) → ~microseconds if cached
                            → DynamoDB if cache miss (~1–10ms)

DAX is a cluster (primary + replicas) deployed in your VPC
  → Only accessible within VPC (not public)
  → Drop-in replacement: change endpoint in SDK, code stays same

Write-through cache:
  Write → DAX → DynamoDB → both updated
  → Reads immediately see updated data from cache

Table: Users (Global Table)
  us-east-1 replica:    App writes user-001 ← write here
  eu-west-1 replica:    EU users read/write ← replicated from us-east-1
  ap-southeast-1:       APAC users read/write

Replication: DynamoDB Streams-powered, async, typically < 1 second

Active-active: any region can accept writes
  → Last-writer-wins for conflict resolution (based on timestamp)

Manual snapshot → full table backup
Stored indefinitely (until deleted)
Restores to new table (does not overwrite existing)
No RCU consumption during backup

Enable PITR → DynamoDB continuously backs up table
Restore to any second in last 35 days
Restore creates new table — original table untouched
No performance impact on production table

Add attribute: "expires_at": 1780000000  (Unix timestamp)
Enable TTL on table, point to "expires_at"
DynamoDB: periodically scans for expired items → deletes them within ~48 hours

Important:
  - Not real-time — deletion can be up to 48 hours after expiry
  - Expired-but-not-deleted items still returned in reads until deleted
  - Add FilterExpression to exclude expired items if needed:
    FilterExpression: "expires_at > :now"

Use cases: sessions, OTPs, cache, temporary tokens, rate limiting counters

-- PartiQL query
SELECT * FROM Orders WHERE user_id = 'u-001' AND order_date > '2026-01-01'

-- Still uses partition key internally — no full table scans without PK
-- Easier for developers who know SQL but want DynamoDB's scale

{
  "Effect": "Allow",
  "Action": ["dynamodb:GetItem", "dynamodb:PutItem"],
  "Resource": "arn:aws:dynamodb:us-east-1:123:table/UserData",
  "Condition": {
    "ForAllValues:StringEquals": {
      "dynamodb:LeadingKeys": ["${aws:userid}"]
    }
  }
}