If you cannot architect a database that handles millions of requests per second, your application will crash during peak traffic and your organisation will lose customers. That is the problem Amazon DynamoDB solves: it is a NoSQL database built for high-throughput workloads where every millisecond matters. For the DEA-C01 exam, you need to understand when to choose DynamoDB over traditional databases and how it stores data using keys and values.
Jump to a section
A simple way to picture Amazon DynamoDB: NoSQL Key-Value and Document Database for High-Throughput Workloads
Inside a massive supermarket during a holiday rush. The store has two completely different ways to check out.
First, there are the staffed lanes with a cashier. Each lane has one cashier who can handle any type of item. You can buy bananas, a frozen pizza, and a pack of batteries all at once. The cashier knows the weight of each item, checks for discounts, and handles price adjustments. This is like a traditional relational database, where one server processes every request and can look up any piece of information you need. But if the store is packed, adding more cashiers (scaling horizontally) is hard because you need more physical space and more training.
Now, look at the self-checkout machines. Each machine is simpler. It only needs to recognise the barcode or an image of the item. It does not need to know anything about the item's history, its weight, or if it's on sale. You just scan the barcode, pay, and leave. The machine treats every item as a simple code (the key) and a price (the value). If the store is overwhelmed, they can just wheel in more identical self-checkout machines — they all behave the same way. This is DynamoDB. It lets millions of customers (users) scan their items (read/write data) at high speed without slowing down.
Each staffed lane with a cashier is a relational database. Each self-checkout machine is a DynamoDB table. The barcode is the primary key (a unique identifier), and the price and item description are the value (the document). The store's layout never changes even when hundreds of machines are added — DynamoDB gives you that same scalability without redesigning the database.
DynamoDB is a fully managed NoSQL database service provided by Amazon Web Services (AWS). Let's break that down.
'Fully managed' means AWS takes care of all the behind-the-scenes work — hardware maintenance, software patching, backups, and scaling. You do not need to worry about which server the database runs on or when to add more storage space. You just tell DynamoDB what data to store and how fast you need to access it.
'NoSQL' stands for 'Not Only SQL'. Traditional databases (like MySQL or PostgreSQL) use SQL a structured query language that organises data into rigid tables with rows and columns. In a relational database, every row in a table has the same columns. If you want to add a new column, you must change the entire table design, which can be slow and inflexible. NoSQL databases like DynamoDB are more flexible. You store data as an item (a single record) and each item can have different attributes (fields). This is called a 'schema-less' design.
DynamoDB is both a key-value store and a document database.
A key-value store works like a giant dictionary. Every item has one unique identifier called the 'primary key' (the key). You can think of it like a locker number. If you know the locker number, you can instantly open that locker and see whatever is inside (the value). The value can be anything: a number, a string of text, or even a whole nested document containing lots of information.
A document database stores data as documents, usually in JSON format (a way of organising data that humans can read). DynamoDB can store an entire document as the value for a single key. For example, a user profile might be a document containing their name, email address, shipping addresses, and order history all nested inside one 'value'.
Now, why does DynamoDB exist? Relational databases become a bottleneck when you need to serve millions of users at once. Imagine a ticketing website for a concert: when tickets go on sale, thousands of people hit the website in the same second. A relational database would struggle because every single ticket lookup involves checking locks, verifying constraints, and writing to multiple tables. DynamoDB handles this by distributing data across many servers automatically. It can scale horizontally, meaning you can add more machines to handle more traffic without any downtime.
In DynamoDB, data is stored in 'tables'. A table is a collection of items. Each item has a 'primary key', which is either a single value (called a partition key) or a combination of two values (partition key and sort key). The partition key is used to spread data across multiple servers. DynamoDB uses the partition key to decide which server (or partition) stores that item. This is how it achieves high speed: when you fetch an item by its partition key, DynamoDB knows exactly which server to ask.
The sort key is an optional second part of the primary key. It lets you organise items that share the same partition key into a sorted order. For example, you might have a partition key of 'UserID' and a sort key of 'OrderDate' to retrieve all orders for a specific user in date order.
DynamoDB offers two read/write capacity modes: provisioned and on-demand. - Provisioned capacity: You specify exactly how many read and write operations per second you expect. This is like reserving a certain number of self-checkout machines. It costs less for steady traffic but you pay for unused capacity. - On-demand capacity: DynamoDB automatically scales up and down based on traffic. You pay only for what you use. This is more expensive but perfect for unpredictable workloads.
DynamoDB also supports features like:
Global tables: replicate your table across multiple AWS regions (geographic locations) for disaster recovery and low-latency access worldwide.
DynamoDB Accelerator (DAX): an in-memory cache that speeds up reads by storing the most frequently accessed data in memory.
Transactions: allow you to read or write multiple items as a single, all-or-nothing operation.
Time to Live (TTL): automatically delete items after a certain time. Great for session data that should expire.
Streams: capture a time-ordered sequence of item-level changes to your table, which can trigger AWS Lambda functions to process data in near real-time.
Why does this replace traditional databases? Because for many modern applications like gaming leaderboards, shopping carts, user sessions, and IoT sensor data, you need to write millions of records and read them in milliseconds. DynamoDB is built for that exact scenario.
Create a DynamoDB Table
In the AWS Management Console, navigate to DynamoDB and click 'Create table'. You must provide a table name and a primary key (either a partition key alone, or a partition key plus a sort key). You also choose the capacity mode: provisioned or on-demand. This step is critical because you cannot change the primary key later.
Define Primary Key and Secondary Indexes
Based on your access patterns, decide the partition key (high-cardinality attribute like UserID) and optionally a sort key (like Timestamp). If you need extra query patterns, create a Global Secondary Index (GSI) or Local Secondary Index (LSI). Remember, LSIs must be defined at table creation.
Configure Read/Write Capacity
If using provisioned capacity, set the number of Read Capacity Units (RCUs) and Write Capacity Units (WCUs) per second. Use DynamoDB auto-scaling to adjust automatically based on utilisation. For unpredictable workloads, choose on-demand capacity but expect higher per-request charges.
Write Data Using PutItem or BatchWriteItem
To insert an item into the table, use the PutItem API call and provide a JSON object containing the primary key and other attributes. BatchWriteItem can write up to 25 items at once. DynamoDB validates the primary key and stores the item across the appropriate partition servers.
Query Data Using Query or GetItem
Use GetItem to fetch a single item by its primary key (fastest operation). Use Query to retrieve all items with the same partition key, optionally filtering by sort key range. Never use Scan for production queries unless you need to export the entire table, as it reads every item and consumes significant capacity.
Enable DynamoDB Streams and Global Tables (Optional)
To react to changes in real-time, enable DynamoDB Streams which capture item-level modifications. For multi-region replication, set up Global Tables. This step adds complexity but is essential for high-availability requirements tested on the DEA-C01 exam.
Imagine you work for a company that runs a popular mobile game called 'Quest of the Crystal Unicorn'. Millions of players log in each day to collect rewards, fight monsters, and update their scores. The game needs to save each player's progress in real-time. If the database cannot keep up, players experience lag or lose their progress — they will quit the game.
As a data engineer, you are responsible for designing the database layer. Here is exactly what you do with DynamoDB:
First, you identify what data needs to be stored. The game has:
Player profiles (username, level, experience points, inventory)
Game state (current quest, health points, location)
Leaderboard scores (player name, high score)
In-game purchase receipts (transaction id, amount, item bought)
You decide to use DynamoDB for the player profiles and game state because they need fast single-item lookups. You choose a relational database for the purchase receipts because the finance team needs complex aggregated reports. This is called a polyglot persistence approach — using the right tool for each job.
For player profiles, you create a DynamoDB table called 'PlayerProfiles'. The primary key is 'PlayerID' (a unique string assigned to each player). The rest of the item contains attributes like 'UserName', 'Level', 'ExperiencePoints', and 'Inventory' (which is a list of items). Because DynamoDB is schema-less, each player can have different items in their inventory without needing to change the table design.
Now, the leaderboard. You create a table called 'Leaderboard'. The partition key is 'Continent' (e.g. 'NorthAmerica', 'Asia') and the sort key is 'Score'. You store the player name as an attribute. When a player finishes a level, the game calls DynamoDB to update their score. DynamoDB automatically sorts the items within each partition by score, so retrieving the top 10 players in a region is a fast single API call using the 'Query' operation with a limit of 10 and scanning in reverse order.
The real-world steps you follow:
Design the table schema: choose the partition key and sort key carefully to ensure even data distribution. If you choose a poor partition key (like 'PlayerType' that only has two values), then only two servers handle all the traffic, causing a hot partition.
Configure read/write capacity: for the mobile game, traffic spikes when a new event launches. You choose on-demand capacity to handle the spike without manual intervention.
Set up auto-scaling: even with provisioned capacity, you can set DynamoDB to add more capacity when usage hits a threshold. This saves money during quiet periods.
Enable DynamoDB Streams: you enable streams on the 'PlayerProfiles' table so that whenever a player's level changes, a Lambda function is triggered to send a congratulatory notification.
Implement global tables: to handle players in Europe and Asia, you set up global tables so that each region's players read from a local copy. Writes are automatically propagated across regions.
Monitor with Amazon CloudWatch: you set up alarms to alert you if read or write throttling occurs (when requests exceed capacity). Throttling causes errors that players see as 'Service Unavailable'.
Back up with on-demand backups: you schedule periodic on-demand backups to protect against accidental data deletion.
In practice, you spend most of your time deciding the partition key and sort key, because that single decision determines whether your application runs smoothly at scale or crashes.
The DEA-C01 exam will test your understanding of DynamoDB through scenario-based questions. You will be given a business requirement (e.g., 'an application needs to store user session data for millions of users with single-digit millisecond latency') and you must choose the right DynamoDB feature or configuration.
Here are the specific concepts the exam loves to target:
Partition key vs sort key. A common question: 'Your application needs to query all orders for a customer by date. Which primary key design should you use?' Correct answer: partition key of CustomerID, sort key of OrderDate. Trap: using only a partition key without a sort key means you cannot retrieve a range of items without a full scan.
Read capacity units (RCUs) vs write capacity units (WCUs). The exam expects you to understand how to calculate them. For a strongly consistent read of an item up to 4KB, one RCU equals one read per second. For an eventually consistent read, one RCU equals two reads per second. For a write of an item up to 1KB, one WCU equals one write per second. Questions will give you a dataset size and number of operations per second and ask you to calculate required capacity.
Strong consistency vs eventual consistency. DynamoDB defaults to eventually consistent reads. Trap: the exam will present a scenario where after writing, you immediately read the same item and get stale data. The answer is to use strongly consistent reads, but note they cost double the RCUs and have higher latency.
Indexing: Local Secondary Index (LSI) vs Global Secondary Index (GSI). LSI must be created at table creation and shares the same partition key as the table. GSI can be added later and has its own partition key and sort key. Trap: you cannot add an LSI after the table is created, but many candidates think you can.
Time to Live (TTL): the exam tests that TTL deletes items within 48 hours of the TTL timestamp, and that it costs no write capacity because the deletion is asynchronous. Trap: they ask 'when does DynamoDB delete the item?' and offer 'immediately', 'within 48 hours', 'at the exact second of the TTL'. Correct: within 48 hours.
DynamoDB Accelerator (DAX): used to reduce read latency from single-digit milliseconds to microseconds. Trap: DAX is an in-memory cache, not a replacement for DynamoDB tables. It is best for read-heavy workloads with predictable access patterns.
Global tables: used for multi-region active-active replication. Trap: the exam will ask which feature supports disaster recovery with low-latency reads in multiple geographic regions. Correct: global tables.
Transactions: DynamoDB supports ACID transactions (Atomicity, Consistency, Isolation, Durability) across up to 25 items or 4MB of data. Trap: questions will present a scenario requiring atomic multi-item operations and ask which DynamoDB feature to use — the answer is 'transactions', not 'PutItem with conditional writes'.
Conditional writes and optimistic locking: the exam tests that you can prevent overwriting data by using a condition expression like 'attribute_not_exists(ItemID)' or a version number attribute. Trap: they describe a scenario where two processes try to update a counter and ask how to avoid race conditions. Correct: use atomic counters or conditional updates.
Common question patterns: - 'Which DynamoDB feature should you use to ...?' - 'What is the most cost-effective solution for ...?' - 'What is the primary key design that allows for ...?'
The incorrect answers often suggest using features that exist but are suboptimal, like using 'Scan' instead of 'Query', or using a relational database for high-throughput workloads. Always look for the option that leverages DynamoDB's strengths: horizontal scaling, low latency, and schema flexibility.
DynamoDB is a fully managed NoSQL database that stores data as items with a primary key and arbitrary attributes, enabling schema-less design.
The partition key determines which server stores an item, and the sort key enables range queries within a partition.
DynamoDB supports two capacity modes: provisioned (reserved throughput) and on-demand (auto-scaling based on traffic).
Local secondary indexes (LSIs) must be created at table creation time, while global secondary indexes (GSIs) can be added to any existing table.
DynamoDB Accelerator (DAX) is an in-memory cache that reduces read latency from milliseconds to microseconds for read-heavy workloads.
Global Tables provide multi-region active-active replication with eventual consistency for disaster recovery and low-latency access.
Conditional writes allow you to prevent overwriting data unless a specified condition is met, enabling optimistic locking.
Time to Live (TTL) deletes items automatically after a specified timestamp at no extra cost, useful for expiring sessions or logs.
These come up on the exam all the time. Here's how to tell them apart.
DynamoDB
Schema-less: items can have different attributes within the same table
Scales horizontally by adding partitions across multiple servers
Queries are limited to primary key and index operations
Amazon RDS (Relational Database)
Fixed schema: every row must have the same columns defined in advance
Scales vertically (larger instance) or horizontally with read replicas
Supports complex joins, subqueries, and aggregations using SQL
DynamoDB On-Demand Mode
Automatically scales up and down based on actual traffic
No need to forecast traffic; pay per request
More expensive per request for predictable workloads
DynamoDB Provisioned Mode
You specify read/write capacity units in advance
Requires capacity planning; can use auto-scaling
Lower cost per request for steady, predictable traffic
Partition Key Only
Simple primary key: just one value used to distribute data
Cannot query a range of items; only single-item lookups by primary key
Useful for small items with unique identifiers (e.g., user session)
Partition Key + Sort Key
Composite key: partition key for distribution, sort key for ordering
Supports queries that return all items with the same partition key sorted by sort key
Ideal for one-to-many relationships (e.g., all orders for one customer)
Strongly Consistent Read
Guarantees the most recent write is returned
Double the read capacity units cost
Higher latency because it must contact the primary partition copy
Eventually Consistent Read
May return stale data if a write just occurred
Half the read capacity units cost
Lower latency because it can read from a replica
Local Secondary Index (LSI)
Must be created at table creation time
Shares the same partition key as the base table
Supports strong consistency on queries
Global Secondary Index (GSI)
Can be added to an existing table at any time
Has its own partition key (can differ from base table)
Only supports eventual consistency on queries
Mistake
DynamoDB is just a simple key-value store that cannot handle complex queries.
Correct
DynamoDB supports rich querying capabilities including filtering, projection expressions, secondary indexes, and PartiQL (a SQL-compatible query language). It can perform complex queries as long as they are based on the primary key or indexes.
People confuse the simplicity of the core abstraction with limited functionality. They assume 'key-value' means you can only look up a single item at a time.
Mistake
DynamoDB automatically sorts items globally when you use a sort key.
Correct
DynamoDB only sorts items within the same partition key value. It does not sort items across different partition keys. To get globally sorted data, you need a single partition key, but that limits throughput because all items are on one server.
The exam industry often uses 'sort key' which sounds global, but in practice it only applies within a partition.
Mistake
You can change the primary key of a DynamoDB table after creation.
Correct
You cannot modify the primary key schema (partition key or sort key) of an existing table. If you need a different key design, you must create a new table and migrate data.
Many beginners are familiar with relational databases where you can add new columns or change indexes after creation. DynamoDB's schema is fixed at creation time.
Mistake
DynamoDB is always cheaper than a relational database.
Correct
DynamoDB can be more expensive than relational databases for workloads with low traffic or complex queries. It is cost-effective for high-throughput scenarios but not necessarily for small-scale applications.
AWS marketing emphasises 'pay per request' which sounds cheap, but for predictable low traffic, a fixed-cost relational database can be far cheaper.
Mistake
DynamoDB transactions are the same as relational database transactions.
Correct
DynamoDB transactions support ACID properties but are limited to up to 25 items or 4MB of data per transaction. They also cost additional capacity units. Relational databases support unbounded transaction sizes and more complex isolation levels.
The term 'transaction' is overloaded. Beginners assume feature parity with traditional databases.
Mistake
DynamoDB Global Tables guarantee strong consistency across all regions.
Correct
Global Tables offer eventual consistency across regions. Writes are typically replicated within seconds but there is no guarantee of immediate consistency. For strong consistency, you must read from the region where the write occurred.
The word 'global' implies instant uniformity, but distributed systems cannot achieve strong consistency across geographic distances without significant latency trade-offs.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Eventually consistent reads might return stale data within a second of a write, but they cost half the read capacity units. Strongly consistent reads always return the most up-to-date data but have higher latency and cost double the RCUs.
No, you cannot modify the primary key (partition key or sort key) after the table is created. You must create a new table with the desired key schema and migrate the data using AWS Glue, EMR, or a custom script.
DynamoDB automatically distributes items across multiple servers (partitions) based on the partition key. As traffic increases, it adds more partitions behind the scenes. This horizontal scaling allows it to handle millions of requests per second.
A hot partition occurs when too many requests hit a single partition because the partition key has low cardinality (e.g., only two distinct values). To avoid it, choose a high-cardinality partition key (e.g., UserID or SessionID) that distributes requests evenly, or use write sharding.
Use DynamoDB when you need single-digit millisecond latency at any scale, have unpredictable or spiky traffic, need a schema-less data model, or handle simple key-based lookups. Use RDS for complex queries, joins, multi-row transactions, or data with rigid schemas.
An LSI must be created when you create the table, shares the same partition key as the base table, and offers strong consistency. A GSI can be added to an existing table, has its own partition and sort key, and offers only eventual consistency.
DynamoDB charges based on read/write capacity units (provisioned mode) or per-request pricing (on-demand mode). You also pay for data storage and backup costs. There is no charge for table creation or deletion. DAX and Global Tables incur additional charges.
You've finished Amazon DynamoDB: NoSQL Key-Value and Document Database for High-Throughput Workloads. Continue through the DEA-C01 study guide to build a complete picture of the exam.
Done with this chapter?