Amazon DynamoDB
Amazon DynamoDB is a fully managed, serverless key-value and document database that delivers single-digit-millisecond performance at virtually any scale. It's a frequent answer for "serverless", "massive scale", "session data" and "least operational overhead" scenarios.
Data model
- Table → items (rows) → attributes (columns, flexible per item).
- Each item is identified by a primary key:
- Partition key alone (e.g.
userId), or - Partition key + sort key (e.g.
customerId+orderDate) — enables range queries within a partition.
- Partition key alone (e.g.
- Item size up to 400 KB — store larger objects in S3 and keep a pointer.
- Choose a partition key with high cardinality so traffic spreads evenly (avoid "hot partitions").
Capacity modes
| On-demand | Provisioned | |
|---|---|---|
| Pricing | Pay per request | Pay for read/write capacity units per hour |
| Scaling | Instant, automatic | Set capacity; use auto scaling to adjust |
| Best for | Unpredictable or spiky traffic, new apps | Predictable traffic — usually cheaper at steady load (plus reserved capacity) |
Capacity unit maths (provisioned)
- 1 RCU = one strongly consistent read per second of an item up to 4 KB (or two eventually consistent reads).
- 1 WCU = one write per second of an item up to 1 KB.
- Transactional reads/writes cost double.
Example: 100 strongly consistent reads/second of 6 KB items → each read needs 2 RCU (6 KB rounds up to 8 KB) → 200 RCU. Eventually consistent → 100 RCU.
Indexes
| Global secondary index (GSI) | Local secondary index (LSI) | |
|---|---|---|
| Keys | Different partition and sort key | Same partition key, different sort key |
| Create | Any time | Only at table creation |
| Capacity | Its own | Shares the table's |
| Consistency | Eventually consistent reads | Strong or eventual |
Use indexes for alternative query patterns (e.g. look up orders by status).
Performance and caching
- DynamoDB Accelerator (DAX) — in-memory cache for DynamoDB, microsecond reads, API-compatible (minimal code change). For read-heavy workloads with repeated reads.
- ElastiCache is for general caching; DAX is specific to DynamoDB.
Streams and events
- DynamoDB Streams — a time-ordered log of item changes (kept 24 hours); trigger Lambda for event-driven processing (send email on new order, update a search index, aggregate data).
- Kinesis Data Streams integration for longer retention and more consumers.
Global tables
Multi-Region, multi-active replication: every Region accepts reads and writes, with changes replicated asynchronously (typically within a second or so). For globally distributed apps and Region-level resilience.
Other features
| Feature | Use |
|---|---|
| TTL | Automatically delete expired items (sessions, temporary data) at no cost |
| Transactions | ACID operations across multiple items/tables |
| Point-in-time recovery | Restore to any second in the last 35 days |
| On-demand backups | Full backups kept until deleted |
| Export to S3 | Analyse with Athena without consuming table capacity |
| Standard-IA table class | Lower storage cost for rarely accessed tables |
| Encryption | Always at rest; choose key type |
| Gateway VPC endpoint | Private access from VPCs, free |
When DynamoDB fits (and doesn't)
| Good fit | Poor fit |
|---|---|
| Known access patterns by key | Ad-hoc queries, complex joins, reporting |
| Massive scale, unpredictable traffic | Heavy relational integrity across many tables |
| Serverless apps, sessions, carts, gaming, IoT, metadata | Analytics over the whole dataset (use Athena/Redshift on exports) |
Exam patterns
- "Serverless app needs a database that scales automatically with no management" → DynamoDB (on-demand).
- "Read-heavy DynamoDB table needs microsecond latency" → DAX.
- "Act on every new item written to a table" → DynamoDB Streams + Lambda.
- "Users in multiple Regions read and write with low latency" → global tables.
- "Automatically remove sessions after 24 hours" → TTL.
Senior Full-Stack Engineer · AI & AWS. I design and run production systems on AWS — serverless, data and AI.