DynamoDB — Concept
What it is
Amazon DynamoDB = fully managed, serverless, NoSQL key-value and document database with single-digit-millisecond latency at any scale, multi-AZ by default.
Why it exists
Relational DBs struggle at very high request rates and require capacity planning. DynamoDB solves: massive scale, predictable latency, no servers, and integrates natively with serverless (Lambda, API Gateway).
Data model
- Table → composed of items (rows).
- Primary key = either:
- Partition key (PK) only — hash partitioning.
- PK + Sort key — items grouped under same PK, sorted by SK; supports range queries.
- Each item up to 400 KB.
- Schemaless except for the PK/SK; attributes can vary per item.
Capacity modes
| Mode | Pricing | Use |
|---|
| On-Demand | Pay per request, instant scale | Spiky / unknown traffic, dev/test |
| Provisioned | Pay per RCU/WCU/hour | Predictable traffic, cheaper at scale; supports Auto Scaling |
- 1 RCU = 1 strongly-consistent read of 4 KB / sec (or 2 eventually-consistent).
- 1 WCU = 1 write of 1 KB / sec.
Consistency
- Eventually consistent reads (default, cheaper).
- Strongly consistent reads (1 RCU = 4 KB, double the cost).
- Transactions (TransactWrite/TransactGet) — ACID across multiple items/tables, 2× cost.
Secondary indexes
| Index | Where | Notes |
|---|
| LSI (Local Secondary Index) | Same PK, different SK | Created at table creation only, up to 5 per table, strong consistency option |
| GSI (Global Secondary Index) | Different PK and/or SK | Created/deleted anytime, up to 20 per table (soft), eventually consistent only, separate throughput |
DAX
- DynamoDB Accelerator = in-memory cache that fronts DynamoDB.
- Microsecond reads for cached items.
- Item / query cache.
- Reduces RCUs.
Streams & Triggers
- DynamoDB Streams = ordered change log (24 h retention).
- Trigger Lambda on insert / modify / remove → ETL, replication, fanout.
- Kinesis Data Streams for DynamoDB = export to Kinesis for longer retention/processing.
Global Tables
- Multi-region, multi-active replication (each region accepts writes).
- Underlying conflict resolution: last writer wins.
- For globally distributed apps with low-latency local writes.
TTL
- Per-item expiration; deletes within ~48 h of TTL time (free).
Backups
- PITR (Point-in-Time Recovery) — last 35 days, free granularity.
- On-demand backups — retained until deleted.
- AWS Backup integration.
Security
- IAM policies; fine-grained access at item and attribute level via
dynamodb:LeadingKeys.
- KMS encryption (default AWS-managed key or your own).
- VPC endpoint (interface) for private access.
When to use vs alternatives
| Use ... | Instead of ... | When ... |
|---|
| DynamoDB | RDS / Aurora | Key-value, single-digit ms, massive scale, schemaless |
| DynamoDB + DAX | DynamoDB only | Microsecond-level cache for read-heavy hot keys |
| Global Tables | Aurora Global DB | Multi-active writes globally |
| ElastiCache | DynamoDB | In-memory cache for any workload |
| Aurora | DynamoDB | Need joins, complex queries, full SQL |
Common exam scenarios
- "Serverless session store, scales to millions of users" → DynamoDB On-Demand.
- "Microsecond read latency for hot product catalog" → DynamoDB + DAX.
- "Trigger Lambda when a row changes" → DynamoDB Streams + Lambda.
- "Global app with low-latency local writes in 4 regions" → Global Tables.
- "Atomic transfer between two accounts in DB" → Transactions (TransactWrite).
- "Need to auto-expire records after 30 days" → TTL attribute.
- "Read pattern by alternate key without scanning" → GSI (or LSI if known up-front).
Exam tip
- LSI vs GSI: LSI = same partition key + alternate sort key, must create up-front. GSI = totally different keys, anytime.
- DAX is only for DynamoDB; for other DBs use ElastiCache.
- Use On-Demand when traffic is unknown; Provisioned + Auto Scaling for steady predictable.
References