Amazon DynamoDB Architecture, Keys, Scaling, and Global Tables – SAP-C02 Study Guide

Purpose of This Lesson

Amazon DynamoDB is AWS’s fully managed, serverless NoSQL database. It supports both key-value and document data models and is designed for highly available, low-latency workloads that require seamless horizontal scaling.

For the SAP-C02 exam, focus on when DynamoDB is a better fit than a relational database, how its primary keys organize data, how capacity affects cost and performance, and which features address caching, expiration, change processing, backup, and multi-Region availability.

Key Concepts

Serverless NoSQL database

DynamoDB is non-relational and does not require provisioned database servers to be managed by the customer. It is a suitable choice when an application needs:

• Flexible or evolving item attributes
• High request rates and predictable low latency
• Automatic or easily configured scaling
• Managed high availability and fault tolerance
• Key-value or document-oriented access patterns

DynamoDB does not impose a fixed schema on every item. Items in the same table can have different non-key attributes, which is useful when data structures vary over time.

Tables, items, and attributes

DynamoDB organizes data using three primary concepts:

• Table: A collection of related data.
• Item: A record in the table, conceptually similar to a row.
• Attribute: A data element within an item, conceptually similar to a column.

Unlike a relational table, non-key attributes do not need to exist on every item. However, the table’s primary key requirements must be satisfied.

Primary keys

Every DynamoDB table requires a partition key. The partition key determines how items are distributed across the underlying storage partitions.

A table can use one of two primary key designs:

Key design	Components	Use case
Simple primary key	Partition key only	Each item is uniquely identified by one key value
Composite primary key	Partition key plus sort key	Multiple related items can share a partition key and be ordered or queried using the sort key

With a composite key, the combination of partition key and sort key must be unique. For example, a customer ID can be the partition key and an order timestamp or order ID can be the sort key.

A well-designed partition key distributes requests evenly. A highly concentrated key can create a hot partition and limit performance even when the overall table has sufficient capacity.

Scaling and capacity

DynamoDB scales horizontally by distributing data and request processing across multiple underlying partitions. Scaling does not require changing a database instance type or taking the table offline.

Capacity can be managed using configured read capacity units (RCUs) and write capacity units (WCUs), typically with auto scaling, or by using an on-demand capacity approach where appropriate. The selected capacity model affects cost and how the table responds to changing traffic patterns.

• RCUs represent read throughput.
• WCUs represent write throughput.
• Higher provisioned capacity generally increases cost.
• Auto scaling adjusts provisioned capacity based on utilization targets.
• On-demand capacity is useful for unpredictable or intermittent traffic, while provisioned capacity can be more economical for stable workloads.

The exam may describe “push-button” or seamless scaling. In DynamoDB, scaling is designed to occur without the downtime associated with resizing and rebooting a traditional database instance.

Time to Live (TTL)

DynamoDB TTL lets you designate an expiration timestamp for each item. DynamoDB automatically removes expired items after the TTL value is reached.

TTL is useful for data with a defined retention period, including:

• Session state
• Temporary tokens
• Short-lived event or workflow records
• Application cache metadata

TTL helps control storage growth and avoids the need for an application to scan for expired records and delete them individually. TTL deletions do not consume read or write capacity units. Expiration is asynchronous, so applications should not depend on an item disappearing at the exact timestamp.

DynamoDB Streams

DynamoDB Streams records an ordered sequence of item-level changes. A stream can capture inserts, updates, and deletes so that another component can react to table modifications.

A common architecture uses AWS Lambda to consume stream records and perform tasks such as:

• Updating another data store
• Triggering downstream processing
• Maintaining search indexes
• Auditing or replicating changes

Streams are for change-data processing; they are not a replacement for backups.

DynamoDB Accelerator (DAX)

DynamoDB Accelerator, or DAX, is a fully managed, in-memory cache designed specifically for DynamoDB.

DAX is appropriate when an application requires extremely low-latency reads and can tolerate cached-read behavior. DynamoDB already provides millisecond-level performance for many workloads, while DAX can reduce eligible read latency to the microsecond range.

A major advantage is API compatibility: applications can use a DAX client with minimal code changes rather than implementing a separate caching system. DAX should not be selected simply because a workload needs durable storage or strongly consistent database reads.

Consistency and transactions

DynamoDB supports eventually consistent reads and strongly consistent reads where the access pattern and Region support them. Eventually consistent reads can provide lower cost or higher effective read throughput, while strongly consistent reads are used when the most recent successful write must be immediately visible.

DynamoDB also supports ACID transactions across multiple items and tables within the applicable transaction scope. Transactions are useful when several writes or reads must succeed or fail together, but they add coordination and should not be used unnecessarily for every operation.

Backup and point-in-time recovery

DynamoDB provides:

• Point-in-time recovery (PITR): Continuous recovery capability within a rolling 35-day window, with restoration to a selected point in time.
• On-demand backup: Explicit backups that can be retained and restored independently of the source table’s ongoing activity.

Backups are separate from DynamoDB Streams. PITR and on-demand backups address recovery, whereas Streams support event-driven processing.

Global tables

DynamoDB global tables provide a fully managed, multi-Region, multi-active database architecture. Replicas are deployed in multiple AWS Regions, and applications can read from and write to the appropriate Regional replica. Changes are replicated between Regions.

Global tables are a strong choice for:

• Multi-Region active-active applications
• Lower latency for globally distributed users
• Regional failure resilience
• Disaster recovery designs requiring cross-Region replication

Multi-Region writes introduce conflict-resolution and data-modeling considerations. Applications should avoid conflicting concurrent writes to the same item whenever possible and should account for replication behavior and operational costs.

Exam-Relevant Takeaways

• DynamoDB is a serverless, fully managed, non-relational database.
• It supports key-value and document data models.
• Every table requires a partition key; a sort key is optional.
• Partition key plus sort key forms a composite primary key.
• DynamoDB scales horizontally without traditional database-instance resizing downtime.
• Choose capacity settings based on traffic predictability, utilization, and cost.
• Use TTL for automatic expiration of temporary items; expiration is asynchronous and does not consume RCUs or WCUs.
• Use DynamoDB Streams to react to item-level changes, commonly with Lambda.
• Use DAX when DynamoDB reads need microsecond-class latency and an in-memory cache is appropriate.
• Use PITR for continuous recovery within the supported retention window and on-demand backups for explicit backup copies.
• Use global tables for multi-Region, multi-active replication and Regional access.
• DynamoDB’s flexible item attributes do not eliminate the need for deliberate key and access-pattern design.

Architecture Decision Guide

Requirement	DynamoDB feature or design
Flexible item structure	NoSQL document/key-value model with optional non-key attributes
High throughput without managing database servers	DynamoDB with suitable capacity configuration
Unpredictable or intermittent traffic	On-demand capacity mode
Stable traffic with cost optimization through utilization targets	Provisioned capacity with auto scaling
Automatic removal of temporary records	TTL
React to inserts, updates, or deletes	DynamoDB Streams, often consumed by Lambda
Microsecond-class cached reads	DAX
Restore to a recent point in time	Point-in-time recovery
Retained, explicitly created backup	On-demand backup
Active application access in multiple Regions	DynamoDB global tables
Atomic changes across multiple items	DynamoDB transactions

Common Exam Traps

• Confusing DynamoDB with a relational database: DynamoDB does not use joins, fixed relational schemas, or traditional database instances.
• Assuming every item needs identical attributes: Non-key attributes can vary between items.
• Treating the sort key as mandatory: Only the partition key is required. The sort key is optional.
• Choosing a poor partition key: Low-cardinality or highly skewed partition keys can concentrate traffic and cause hot partitions.
• Assuming TTL deletes items exactly on schedule: TTL expiration is asynchronous and should be treated as eventual cleanup.
• Using Streams as a backup mechanism: Streams capture changes for processing; they do not provide point-in-time recovery.
• Using DAX for writes or durability: DAX is an in-memory caching layer, primarily used to accelerate reads. DynamoDB remains the durable data store.
• Assuming global tables are single-writer by default: Global tables support multi-Region, multi-active operation, so replication and write-conflict behavior must be considered.
• Assuming scaling is free: Increasing provisioned capacity or processing more requests can increase cost, even though scaling does not require downtime.
• Selecting strong consistency without a requirement: Eventually consistent reads may be sufficient and can be more economical for many workloads.

Real-World Engineer Notes

• Start DynamoDB design with access patterns, not with an entity-relational diagram. Determine how the application will retrieve, update, and group items before selecting keys.
• Choose partition key values with high cardinality and an even distribution of requests. A technically valid key can still be operationally poor if most traffic targets one value.
• Use a sort key to model related records, time ordering, hierarchical access, or range-based retrieval within a partition.
• Keep TTL cleanup separate from business-critical deletion workflows. If an application must know exactly when deletion occurred, implement an explicit workflow rather than relying solely on TTL.
• Use Streams for asynchronous integration, but design consumers for retries, duplicate processing, and downstream failures.
• Add DAX only when measured read latency and access patterns justify its operational and infrastructure cost. It is not a universal replacement for application caching.
• For global tables, define Regional routing, conflict avoidance, failure handling, and data ownership rules before enabling multi-Region writes.
• Use PITR as a recovery control and test restoration procedures regularly. A backup feature that has never been restored is not a fully validated recovery strategy.

Quick Reference Summary

• Service type: Serverless, fully managed NoSQL database
• Data models: Key-value and document
• Data hierarchy: Table → item → attribute
• Required key: Partition key
• Optional key: Sort key
• Composite key: Partition key plus sort key
• Scaling: Horizontal, with no traditional instance-resize downtime
• Capacity metrics: RCUs for reads and WCUs for writes
• Expiration: TTL, with asynchronous deletion and no RCU/WCU consumption for TTL removal
• Change processing: DynamoDB Streams
• Read acceleration: DAX, with microsecond-class cached-read latency
• Recovery: PITR and on-demand backups
• Multi-Region: Global tables with multi-active replication

Flashcards

1. Q: What type of database is DynamoDB?

A: A fully managed, serverless NoSQL database supporting key-value and document data models.

1. Q: What key is mandatory for every DynamoDB table?

A: The partition key.

1. Q: What is a composite primary key?

A: A primary key composed of a partition key and a sort key.

1. Q: What is the purpose of the partition key?

A: It identifies an item or item group and determines how data and request traffic are distributed.

1. Q: What does the sort key provide?

A: It distinguishes items sharing a partition key and supports ordering and range-based access within that partition.

1. Q: What are RCUs and WCUs?

A: Read capacity units and write capacity units, which represent configured read and write throughput.

1. Q: When is DynamoDB TTL useful?

A: When items should expire automatically, such as sessions, temporary tokens, or short-lived records.

1. Q: Does TTL delete an item exactly at its expiration timestamp?

A: No. TTL deletion is asynchronous.

1. Q: What does DynamoDB Streams capture?

A: An ordered sequence of item-level inserts, updates, and deletes.

1. Q: What problem does DAX solve?

A: It provides a managed in-memory cache for DynamoDB reads and can reduce latency to the microsecond range.

1. Q: What is the difference between PITR and an on-demand backup?

A: PITR provides continuous recovery within its retention window; an on-demand backup is an explicitly created backup retained independently.

1. Q: What architecture does DynamoDB global tables provide?

A: Multi-Region, multi-active replication with Regional read and write capability.

Practice Questions

Question 1

A company stores web-session records in DynamoDB. Each session is valid for 24 hours, after which it should be removed automatically. The company wants to avoid running periodic scans and delete operations. Which solution is most appropriate?

Correct answer: Configure DynamoDB TTL on each item using an expiration timestamp.

Explanation: TTL automatically removes expired items and avoids the need for application-driven scans and deletes. The cleanup is asynchronous, so it should not be used when deletion must occur at an exact second.

Question 2

An application must process every item change in a DynamoDB table and invoke downstream logic whenever an item is created, updated, or deleted. Which feature should the architect select?

Correct answer: DynamoDB Streams consumed by AWS Lambda.

Explanation: Streams provide an ordered sequence of item-level modifications. Lambda can consume those records and trigger downstream processing. Backups and DAX do not provide this event-processing capability.

Question 3

A global customer-facing application needs users in several Regions to access nearby database replicas. The application must continue serving requests if one Region becomes unavailable, and writes may occur in more than one Region. Which DynamoDB capability best meets the requirement?

Correct answer: DynamoDB global tables.

Explanation: Global tables provide managed multi-Region replication with multi-active access. The application must still account for replication behavior and avoid or resolve conflicting concurrent writes.

Question 4

A DynamoDB workload has unpredictable traffic spikes and long idle periods. The company wants capacity to adapt automatically without manually estimating provisioned throughput. Which option should be considered first?

Correct answer: DynamoDB on-demand capacity mode.

Explanation: On-demand mode is designed for unpredictable or intermittent request patterns and removes the need to configure baseline provisioned capacity. The cost model should still be evaluated against the expected request volume.

Question 5

An application already uses DynamoDB but requires substantially lower read latency for frequently accessed data. The development team wants to avoid implementing a custom cache and prefers a cache that integrates with DynamoDB client APIs. Which service is the best fit?

Correct answer: DynamoDB Accelerator (DAX).

Explanation: DAX is a managed, in-memory cache built for DynamoDB and can provide microsecond-class cached-read latency with limited application changes. It is not a substitute for DynamoDB durability or a solution for point-in-time recovery.