DynamoDB
currentSummary
Fully managed serverless key-value and document database from AWS with single-digit millisecond latency at any scale, automatic horizontal scaling, and multi-region active-active replication via Global Tables.
Primary Use Case
High-scale, low-latency key-value access patterns where schema flexibility, predictable performance, and zero operational overhead are prioritized over complex query capabilities.
Workload Fit
Strengths
Best for
- ·High-scale key-value workloads with known, simple access patterns
- ·Serverless architectures requiring zero database operational overhead
- ·Applications already deep in AWS ecosystem requiring multi-region active-active
- ·Gaming, session management, and IoT telemetry with unpredictable traffic spikes
Excels when
- ·Access patterns are known upfront and fit key-value or single-table design
- ·Traffic is unpredictable or bursty: on-demand mode eliminates capacity planning
- ·AWS lock-in is acceptable and multi-region replication is a requirement
Architectural advantages
- ·Zero operational overhead: AWS manages scaling, replication, and hardware
- ·Global Tables provide multi-region active-active replication with millisecond lag
- ·On-demand mode eliminates capacity planning and absorbs arbitrary traffic spikes
- ·Consistent single-digit millisecond latency regardless of table size
When to Avoid
Avoid when
- ·Workload requires complex ad-hoc queries or relational joins
- ·Access patterns are not known upfront: schema design is extremely difficult to change post-launch
- ·AWS lock-in is unacceptable: DynamoDB has no open-source equivalent
Common misuses
- ·Designing DynamoDB like a relational database: table-per-entity approach leads to expensive joins in application code
- ·Using Scan on production tables: scans are expensive and slow on large tables
- ·Not modeling access patterns before launch: retroactive table redesign requires data migration
Consistency & Transactions
Scaling
Read scalability
On-demand mode scales read capacity automatically with zero provisioning. Provisioned mode allows explicit read capacity unit allocation. DAX (DynamoDB Accelerator) adds in-memory caching layer for microsecond read latency.
Write scalability
On-demand mode scales write capacity automatically without pre-warming. Provisioned mode enables cost optimization at predictable write throughput. Partition key distribution determines actual write scaling: hot partitions are throttled regardless of table-level capacity.
Failure Behavior
Known failure modes
- ·Partition throttling: hot partition keys exceed per-partition throughput limits (3000 RCU / 1000 WCU)
- ·GSI throttling: Global Secondary Indexes have independent capacity limits
- ·Item size limit: items exceeding 400KB are rejected
- ·Query result pagination: scans and queries return max 1MB per call, requiring pagination
Bottlenecks
- ·Per-partition throughput limits throttle hot partition key access regardless of table-level capacity
- ·GSI propagation latency: changes to indexed attributes may not be immediately visible in GSI queries
- ·Item collection size limit (10GB) for items with the same partition key
Degradation patterns
- ·Partition throttling manifests as intermittent 400-level errors (ProvisionedThroughputExceededException)
- ·GSI write amplification multiplies write cost when many GSIs are defined on frequently updated attributes
- ·Cold table reads bypass DAX cache, causing latency spikes after DAX restart
Recovery considerations
- ·Point-In-Time Recovery (PITR) is a one-click restore to any second in the last 35 days
- ·Global Tables conflicts under concurrent writes are resolved with last-writer-wins: not always correct
- ·DynamoDB Streams enable event-driven recovery and CDC patterns but add Lambda operational surface
Operational Pitfalls
- ·Monotonically increasing partition keys (timestamps, sequential IDs) create hot partitions
- ·Not designing access patterns before defining table structure: DynamoDB schema is access-pattern-driven
- ·Using Scan operations on large tables: scans read every item and consume full table capacity
- ·Ignoring GSI write amplification: every indexed attribute write is replicated to each GSI
Architecture Guidance
Common topology roles
Migration notes
- ·From DynamoDB to PostgreSQL: flatten single-table design into relational tables; access pattern analysis is required
- ·To DynamoDB from relational: requires complete data model redesign: not a lift-and-shift migration
- ·Adding DAX: wire-compatible cache layer; validate that eventual consistency from DAX is acceptable
Advisor Guidance
When: scenario has complex query patterns or ad-hoc analytics requirements
DynamoDB cannot perform ad-hoc queries: pair with Elasticsearch or ClickHouse for query flexibility
When: scenario uses sequential IDs or timestamps as partition keys
Monotonically increasing partition keys cause hot partition throttling: add random suffix or hash-based distribution
When: scenario is serverless or has highly variable traffic
Use on-demand capacity mode to avoid provisioned capacity under-provisioning during traffic spikes
Comparison Factors
operational complexity
Low: fully managed; no infrastructure to operate
query flexibility
Very low: access patterns must be known at design time; no ad-hoc queries
vendor lock in
Very high: AWS-native with no open-source equivalent
scalability
Very high: serverless on-demand mode scales to unlimited throughput
Managed Cloud Options
Enables Patterns
Basis
AWS-managed service with publicly documented SLAs and extensive production use at scale
Learning Modules
CAP Theorem and PACELC
Why distributed systems cannot simultaneously provide consistency, availability, and partition tolerance: and how PACELC extends this to the latency-consistency tradeoff that applies even when the network is healthy.
Consistency Models in Distributed Systems
The consistency spectrum from linearizability to eventual consistencywhat each model guarantees, which real systems implement each model, and how to design application code for the consistency level your infrastructure provides.
Eventual Consistency
How eventual consistency models propagate updates across nodes, how convergence windows create read anomalies, how conflict resolution works, and when strong consistency is required instead.
Partition Hotspots
How partition key design determines load distribution, how sequential keys create hotspot partitions, why hotspots cause cascading failures, and how to design partition keys that distribute load uniformly.
Related Architecture Knowledge
Outbound: this entity affects
DynamoDB conditional writes (ConditionExpression) enable distributed leader election by implementing compare-and-swap: only the first writer to claim a leadership token succeeds; concurrent claimants fail with ConditionalCheckFailedException, ensuring exactly one leader is elected.
Tradeoffs
- ·DynamoDB TTL expiry has a 48-hour SLA (not instant): a dead leader's token may persist after TTL in rare cases
- ·Conditional write failure rate under contention is directly proportional to the number of candidates
- ·DynamoDB leader election adds external dependency on DynamoDB availability for all coordination operations
DynamoDB automatically partitions tables across internal shards using the partition key as a shard discriminator. Adaptive capacity redistributes throughput across partitions automatically, but partition key design remains critical for avoiding hot partitions.
Tradeoffs
- ·Write sharding for hot keys requires scatter-gather reads to reassemble results across partitions
- ·Adaptive capacity does not eliminate hot partition limits: it only allows temporary bursting
- ·DynamoDB partition splits are transparent but irreversible: a split table has permanent overhead for low-traffic keys
DynamoDB partitions data by partition key hash; sequential or low-cardinality partition keys cause hot partitions that exceed per-partition throughput limits and receive 400 ProvisionedThroughputExceededException responses.
Full relationship →