DynamoDB
DynamoDB is a fully managed, serverless NoSQL key-value and document database with single-digit millisecond performance at any scale. It automatically replicates data across 3 AZs and scales throughput up and down.
DynamoDB is a massive library with books organized by the first letter of the title (partition key). If 90% of books start with 'A', that shelf is overwhelmed. Spread titles evenly across all letters for a happy librarian (DynamoDB).
Data model: every item needs a partition key (hash key). An optional sort key (range key) enables range queries within a partition. Primary key = partition key alone, or composite = partition key + sort key. Capacity modes: On-Demand (pay per request, automatic scaling) and Provisioned (set RCUs/WCUs, use Auto Scaling). Global Secondary Indexes (GSI): alternate partition key + optional sort key, can index any attributes, have their own capacity. Local Secondary Indexes (LSI): same partition key as table, different sort key, must be created at table creation, uses table's capacity.
Partition key design is critical — a hot partition occurs when one key receives a disproportionate share of traffic (e.g., a popular user ID). Mitigations: write sharding (append a suffix 0-N to the key), scatter-gather, or caching. DynamoDB Streams captures item-level changes for event-driven processing (Lambda integration). Global Tables provide multi-region active-active replication with last-writer-wins conflict resolution. DynamoDB Accelerator (DAX) is an in-memory cache that reduces read latency to microseconds. Transactions: TransactWriteItems and TransactGetItems for all-or-nothing across up to 100 items. Single-table design: model multiple entity types in one table using composite keys and GSIs to support diverse access patterns without JOINs.
DynamoDB excels for high-throughput, predictable-latency workloads where access patterns are known upfront. I design the partition key for even distribution — a hot partition is the most common production failure. GSIs support additional access patterns. I use On-Demand mode for unpredictable traffic and Provisioned with Auto Scaling for predictable workloads. For complex relational queries, DynamoDB is the wrong choice — use RDS or Aurora.
Using a low-cardinality partition key (e.g., status = 'active'/'inactive') that concentrates all traffic on 2 partitions. DynamoDB partitions data by partition key hash — poor distribution causes throttling on hot partitions regardless of total provisioned capacity.