Lesson 3.2: DynamoDB architecture and distributed caching patterns
Designing for Amazon DynamoDB requires a different mindset than relational databases. Instead of modeling tables first, developers design access patterns first, then structure the data around them. Early choices about partition keys, indexes, and capacity define scalability, consistency, and performance.
Partition keys and access patterns
Every DynamoDB query must include the partition key or an index. Query operations efficiently find items based on primary key values. In contrast, Scan examines every item in the table and can be slow and expensive for large datasets. Poor key choice can create “hot partitions,” throttling traffic even if overall capacity is sufficient. Keys should evenly distribute load and align with your main query patterns.
Example: using userId as a partition key distributes traffic evenly across DynamoDB partitions, while a constant key like “app” concentrates all requests on a single partition.
GSIs and LSIs
DynamoDB supports alternative query paths using secondary indexes. Local Secondary Indexes (LSIs) can only be created on tables with a composite primary key (partition key + sort key) and must be defined at table creation. LSIs share the table’s partition key but allow a different sort key and support strongly consistent reads.
Global Secondary Indexes (GSIs) allow entirely new partition and sort keys and can be added after table creation. GSIs scale independently but support only eventual consistency, which can lead to slightly stale reads.
Architecturally, GSIs let you support additional queries without duplicating tables, but every write propagates through the index, increasing cost.
Exam Tip: If a scenario mentions “performance degradation” or “high cost” with DynamoDB, the answer is almost always to replace a Scan with a Query or use a GSI.
Conditional writes and transactions
To ensure idempotency, DynamoDB supports conditional writes:
{
"ConditionExpression": "attribute_not_exists(userId)"
}
Transactions provide atomic operations across multiple items or tables, offering ACID guarantees. They incur higher latency and cost, so use them when consistency is critical, such as processing retries from Lambda or SQS events.
TTL, Streams, and event-driven design
DynamoDB’s TTL automatically deletes items after a timestamp, useful for session data or temporary states. Streams capture item-level changes, enabling event-driven workflows with Lambda. Developers must handle retries and eventual consistency when using Streams to trigger downstream processing.
Capacity modes and scaling
DynamoDB offers provisioned and on-demand capacity modes. Provisioned mode defines read/write units with optional auto-scaling; on-demand automatically adapts to traffic. Throttling results in ProvisionedThroughputExceededException, which requires retry logic with exponential backoff.
Caching strategies
Even with horizontal scaling, high-read workloads benefit from caching. Redis can store frequently accessed items, sessions, or leaderboard counters. The pattern is to write authoritative data to DynamoDB and cache read-heavy data in Redis, invalidating or updating the cache on writes. Proper cache invalidation ensures consistency.
DynamoDB Accelerator (DAX) provides a fully managed, in-memory cache for DynamoDB tables. It offers microsecond response times for read-heavy workloads and integrates transparently with DynamoDB, reducing the need for custom caching layers.
Integrated developer mindset
A DynamoDB architecture is about behavior under load, not table creation. Key considerations include:
- Partition key design → ensures even distribution and scalability
- GSIs/LSIs → enable alternative query paths
- Conditional writes and transactions → enforce idempotency and atomicity
- Streams → decouple writes for event-driven workflows
- Capacity mode → dictates scaling flexibility
- ElastiCache → offload read-heavy workloads
By designing around access patterns, retries, and caching, developers ensure predictable behavior, scalable performance, and resilience.
My name is Naeem ul Haq. I’ve been working with AWS since its early days and have deep expertise across its evolving ecosystem.
