DynamoDB & Caching

DynamoDB & Caching Quick Notes

DynamoDB Basics

• Serverless key-value / document store; single-digit ms; multi-AZ by default.
• Access: Prefer Query over Scan.
• Hot partitions / throttling: ProvisionedThroughputExceeded → capacity or key design issue.

Capacity Modes

Mode: Fit

Provisioned (+ autoscaling): Predictable traffic; optimize cost

On-demand: Spiky / mostly idle / hard to forecast

Indexes

LSI: GSI

Create: At table create time, Anytime

Capacity: Shared with table, Own capacity

Consistency: Strong OK, Eventual only

Streams, TTL, Global Tables, Protection

• Streams: Change data capture for event-driven workflows.
• TTL: Epoch-seconds attribute; background delete (no capacity charge).
• Global tables: Multi-Region active-active.
• PITR: ~35-day window — restore to just before corruption.
• Deletion protection: Blocks accidental DeleteTable.

DAX (DynamoDB Accelerator)

• In-memory cache in a VPC for microsecond reads.
• Good for eventual + high read throughput.
• Do not use when you require strongly consistent reads.
• Leaderboard / in-memory HA: DAX and/or ElastiCache Redis (plain DynamoDB alone is not “in-memory”).

ElastiCache

Redis, Memcached

Structures: Advanced, Simple

HA: Multi-AZ + automatic failover, No replica failover

Backups: Yes, No

• Fit: Read-heavy latency, sessions, hot keys in front of RDS/Aurora/PostgreSQL.
• Not for: Write-heavy system of record, SQL JOINs, ETL engines.
• OpenSearch / RDS / Redshift are not DynamoDB caches.

Pick the Data Store

Need: Service

Massive key-value / GPS points: DynamoDB

Graph relationships (“who knows whom”): Neptune

Durable NoSQL + elastic concurrency: DynamoDB (+ DAX optional)

Cache only: ElastiCache