Exam objective 1.3 requires you to design NoSQL database solutions and select appropriate services based on access patterns. This chapter explains how to choose between DynamoDB, ElastiCache, and DocumentDB by understanding the questions your application will ask of its data. For the DBS-C01 exam, you must know not just what each service is, but exactly when to use each one.
Jump to a section
A simple way to picture Non-Relational Database Design (DynamoDB, ElastiCache, DocumentDB)
A warehouse manager who runs a busy distribution centre. This manager has to organise thousands of different products — from toothpicks to tractor tyres — so that any item can be found and shipped within seconds. The manager does not store everything in a single, rigidly organised filing cabinet sorted by one property like 'product size'. Instead, the manager designs a system based entirely on how items are retrieved.
For fast-moving, individually looked-up items like bestselling phone chargers, the manager keeps a small, lightning-fast counter at the front of the warehouse. This counter, staffed by a dedicated assistant, hands over the item immediately without making the picker walk through aisles. This is ElastiCache — a cache that holds frequently accessed data in super-fast memory.
For products that come with a flexible, detailed label (like a 'product sheet' that can have any number of attributes — colour, review score, compatibility), the manager assigns each a unique barcode and stores the sheet in a vast, flexible shelf system. You can look up the sheet by its barcode, but you cannot easily ask 'find all red things' unless you designed the barcode system to include colour. This is DynamoDB — a fast, flexible, key-value database.
For products that look more like documents — instruction manuals, assembly guides, warranty certificates — the manager puts them in a separate filing area where the full content of each document is searchable. The filing area treats each document as a single object and lets you search inside its text. This is DocumentDB — a document database built for JSON-like data. Each storage method exists because the way people ask for things determines the best place to put them.
Non-relational databases, or NoSQL databases, store data differently from the traditional relational databases you may have heard about (like SQL Server or MySQL). Instead of organising data into rigid tables with rows and columns and requiring a strict schema (a predefined structure), NoSQL databases are designed to be flexible. They can handle huge amounts of data, scale out easily across many servers, and are optimised for specific access patterns — meaning the way your application asks for data.
For the AWS Certified Database Specialty DBS-C01 exam, you need to focus on three key NoSQL services: DynamoDB (a key-value and document database), ElastiCache (an in-memory cache), and DocumentDB (a document database compatible with MongoDB). Each solves a different problem, and the exam tests your ability to match the service to the access pattern.
DynamoDB is a fully managed, serverless, key-value and document database. 'Key-value' means every item in the database is stored with a unique identifier (the 'key') and a blob of data (the 'value'). If you know the key, you can retrieve the value extremely quickly — usually in single-digit milliseconds. DynamoDB is ideal for applications that need consistent, low-latency access to data at any scale, such as user profiles, session state, shopping cart contents, or game leaderboards. It supports 'eventual consistency' (data changes may take a moment to appear everywhere) and 'strong consistency' (you always see the latest write). One of DynamoDB's most powerful features is 'auto-scaling' — it automatically adjusts its capacity to handle traffic spikes without manual intervention.
ElastiCache is a fully managed in-memory caching service. 'In memory' means the data is stored in RAM, not on disk, making it incredibly fast. ElastiCache can run either Redis or Memcached, two popular caching engines. You use ElastiCache to store the results of expensive database queries, session data, or frequently accessed objects so that your application can serve them without hitting the main database every time. This dramatically reduces latency and load on your primary database. A common pattern is to put ElastiCache in front of a relational database to absorb read-heavy traffic. The exam expects you to know that ElastiCache is for temporary, fast-access data that can be recomputed or reloaded if the cache fails — it is not a durable, long-term storage solution.
DocumentDB is a fully managed document database that is compatible with MongoDB. 'Document database' means it stores data as JSON-like documents (called 'documents') that can have varying structures. Unlike DynamoDB, which is primarily focused on key-based lookups, DocumentDB allows rich querying on any field inside the document. It supports indexing, aggregation pipelines, and transactions. You would choose DocumentDB when your application has complex query requirements, nested data structures, or needs MongoDB compatibility. For example, a content management system that stores blog posts with comments, tags, and metadata in a flexible schema would be a good fit for DocumentDB.
The key to selecting the right service is to analyse the 'access pattern' — how often is the data read? Written? Is it always looked up by a single ID? Or do you need to search by multiple attributes? Does the data change frequently? Can it be regenerated if lost? The exam rewards candidates who can systematically answer these questions before picking a service.
Identify the Access Pattern
Write down how your application will interact with the data. Will it always look up by a single unique identifier (like a user ID or product ID)? Or will it need to filter by multiple attributes (like 'all products with category X and price above Y')? This is the most critical step for the exam.
Determine Durability Requirements
Decide if the data must survive a server crash or power failure. If yes, choose DynamoDB or DocumentDB. If the data can be lost or regenerated from another source, ElastiCache is an option.
Evaluate Read-to-Write Ratio
If the data is read very frequently (e.g., product catalogue for an e-commerce site) but written rarely, placing an ElastiCache in front of a database can improve performance. If the data is written and read equally often, DynamoDB or DocumentDB might suffice without a cache.
Assess Query Complexity
If queries involve nested fields, aggregation pipelines, or sorting on multiple fields, DocumentDB is the best fit. If queries are simple 'get by key' or 'get by a single secondary index', DynamoDB is better.
Select the Service
Based on the first four steps, pick the service. For key-based, durable, high-scale: DynamoDB. For complex, flexible queries with MongoDB compatibility: DocumentDB. For temporary, super-fast caching: ElastiCache (Redis or Memcached).
Design the Data Model
Once the service is chosen, design the table or collection. For DynamoDB, define the primary key and any secondary indexes. For DocumentDB, define indexes on the fields you query. For ElastiCache, decide the caching strategy (write-through or lazy loading) and set TTL values.
Imagine you are a solutions architect at a company called 'QuickCart', a rapidly growing online grocery delivery service. The company has three distinct data problems that need different NoSQL solutions.
The first problem: the product catalogue. QuickCart has thousands of products, each with a unique product ID. When a customer clicks on a product detail page, the application needs to fetch all details (name, price, description, image URL, weight) by that product ID. The data is read frequently, but the write pattern is simple — just update the product details when the supplier provides new information. The access pattern is 'look up by ID'. This is a textbook case for DynamoDB. You design a table with the product ID as the 'partition key' (the unique identifier). DynamoDB handles the high read traffic effortlessly and scales automatically during peak hours.
The second problem: the shopping cart. When a customer adds items to their cart, the cart data needs to be retrieved and updated very quickly during the checkout flow. However, if a customer closes their browser, the cart does not need to be persisted forever — it can expire after a few days. The data is temporary and needs ultra-fast access. This is the perfect scenario for ElastiCache with Redis. You store the cart as a Redis hash with a time-to-live (TTL) of 48 hours. Every time the customer adds an item, you update the cache. The checkout application reads the cart from ElastiCache in microseconds, without ever touching the main database. If the ElastiCache node fails, the worst case is the customer loses their cart, which is acceptable for this use case.
The third problem: customer reviews. Each product can have many reviews, and customers need to search reviews by date, rating, or customer name. The structure of a review — text, rating, helpful votes, images — is nested and variable. The application needs to run complex queries like 'find all reviews for product X with rating 5, ordered by date'. This complex querying on varied attributes makes DynamoDB difficult to use without multiple secondary indexes. Instead, DocumentDB is the right choice. You store each review as a document, create indexes on the 'productId', 'rating', and 'createdAt' fields, and use MongoDB's aggregation framework to produce the results.
As the architect, your job is to walk through each use case, identify the access pattern, and then map it to the correct AWS service. The exam will give you similar scenarios and ask you to choose between these three services.
The DBS-C01 exam dedicates a significant portion of objective 1.3 to testing your ability to differentiate between DynamoDB, ElastiCache, and DocumentDB based on access patterns. The questions are often presented as scenario-based multiple choice, where you are given a description of an application's data needs and asked to select the best service.
Concepts the exam loves to test:
The difference between 'cache-friendly' and 'database-friendly' workloads.
When to use DynamoDB's 'strongly consistent reads' versus 'eventually consistent reads' (and the cost trade-offs).
The specific use cases for ElastiCache (session store, database caching, real-time leaderboards) and why a relational database is not suitable for those cases.
DocumentDB's MongoDB compatibility and when 'document model' is better than 'key-value model'.
The trade-offs of DynamoDB's 'single-table design' approach.
Common traps the exam sets:
They will describe a high-write, low-read workload and suggest ElastiCache as an incorrect answer (ElastiCache is read-optimised).
They will present a scenario that needs complex queries on multiple fields and trick you into selecting DynamoDB when DocumentDB would be more appropriate.
They will describe a cache that needs to persist data across node failures and suggest ElastiCache (incorrect, unless using Redis with persistence, but even then it is not as durable as a database).
They will ask about 'access pattern' and give a vague description — the correct answer often hinges on whether the data is looked up by ID (DynamoDB) or by multiple attributes (DocumentDB).
Key definitions to memorise for the exam: - 'Partition key': the primary way DynamoDB distributes data across partitions. - 'Time-to-live (TTL)': a feature in DynamoDB and ElastiCache to auto-expire data. - 'Write-through cache': a pattern where data is always written to the cache and the database simultaneously. - 'Lazy loading': a pattern where data is loaded into cache only when it is first requested.
The exam expects you to recite these patterns and justify why one is chosen over the other in a given scenario.
ElastiCache is for temporary, ultra-fast access to data that can be regenerated if lost, not for durable long-term storage.
DynamoDB is the default choice for any access pattern that is primarily a key-based lookup, especially at extreme scale.
DocumentDB is the correct choice when you need MongoDB-compatible querying, including complex aggregations and flexible document schemas.
Access patterns dictate the database choice: 'look up by single ID' leads to DynamoDB, 'search by multiple fields' leads to DocumentDB, 'frequently read data that can be cached' leads to ElastiCache.
You can use ElastiCache in front of any database to reduce read load, but never as the sole copy of important data.
DynamoDB's single-table design can handle many access patterns but requires upfront planning of all query patterns.
If your application requires transactions across multiple documents with ACID guarantees, DocumentDB (or a relational database) may be better than DynamoDB, which has limited transaction support.
Exam questions will try to confuse you by describing a workload that is perfect for one service but using language that hints at another — always map back to access pattern.
These come up on the exam all the time. Here's how to tell them apart.
DynamoDB
Optimised for key-based lookups with low latency.
Supports simple queries via secondary indexes.
Fully managed, serverless, and scales automatically.
DocumentDB
Optimised for complex queries, aggregations, and flexible document structures.
Supports full MongoDB query language with joins and pipelines.
Requires manual scaling or auto-scaling configuration.
DynamoDB
Durable storage: data survives node failures.
Single-digit millisecond latency on reads/writes.
Billed per provisioned capacity or on-demand capacity.
ElastiCache (Redis)
Non-durable cache: data lost on node failure unless persistence is configured.
Microsecond latency for cached data.
Billed by node size and number of nodes.
DocumentDB
Designed for durable storage with replication across AZs.
Supports complex queries on document fields.
Charged for storage, I/O, and compute.
ElastiCache (Redis)
Designed for temporary, high-speed data access.
Does not support complex queries beyond key-based lookups.
Charged for memory and compute only.
DynamoDB (with DAX)
Caching layer for DynamoDB only.
Automatically invalidated on writes to DynamoDB.
Simpler to integrate if your database is DynamoDB.
ElastiCache (Redis)
Can cache data from any database or API.
Requires manual cache invalidation logic.
More flexible for multi-service caching.
Mistake
ElastiCache is a primary database because it's fast and can store data permanently.
Correct
ElastiCache is an in-memory cache, not a durable database. If you restart the node or it crashes, data is lost unless you use Redis persistence, but it's still not designed as a primary store for critical data.
Beginners see 'data store' and assume it is as reliable as a database, not realising RAM is volatile.
Mistake
DynamoDB can handle any type of query efficiently because it's a NoSQL database.
Correct
DynamoDB is only efficient when your access pattern is based on the primary key (or secondary indexes you predefine). Complex queries with multiple filters and sorting across many attributes are very slow or impossible without careful table design.
The term 'NoSQL' is misunderstood as 'can do everything', when each NoSQL database is optimised for specific patterns.
Mistake
DocumentDB is just MongoDB hosted on AWS, so it must be slower than DynamoDB for all operations.
Correct
DocumentDB is a fully managed MongoDB-compatible database that offers similar performance to MongoDB for document queries, but is not designed for simple key-value lookups like DynamoDB. It is faster than DynamoDB for complex queries on nested data.
People assume all AWS services are the same under the hood and that one 'fast' service is the best for everything.
Mistake
If you need to cache database results, you should always use ElastiCache. There is no other option.
Correct
You can also cache data using DynamoDB Accelerator (DAX), which is an in-memory cache specifically for DynamoDB. DAX is often a better choice if your database is DynamoDB, because it integrates more tightly.
Beginners learn about ElastiCache first and fail to recognise that other caching services exist for specific databases.
Mistake
You can choose between DynamoDB and DocumentDB based purely on whether your data is structured or unstructured.
Correct
The choice depends on the access pattern, not the data structure. DynamoDB can store JSON-like data as well as DocumentDB. The difference is whether you need rich querying on multiple attributes (DocumentDB) or ultra-fast key-based access (DynamoDB).
Beginners think 'document database' means only for documents and 'key-value' means only for simple pairs, ignoring the overlap in capability.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
You can, but it will be slower because DynamoDB reads from disk, not from RAM. ElastiCache is designed for microsecond latency, while DynamoDB generally has single-digit millisecond latency. For true caching, ElastiCache is better.
Both store JSON-like data, but DynamoDB is optimised for key-based lookups and simple queries using secondary indexes. DocumentDB allows complex queries, joins (via $lookup), aggregation pipelines, and supports MongoDB's rich query language.
It is strictly a cache. While Redis can persist data to disk, it is not designed to be a primary database. You should always have a durable database (like DynamoDB or a relational database) behind it. Data in ElastiCache can be lost on node failure.
DAX is specifically designed to cache DynamoDB queries. If your database is already DynamoDB, DAX is simpler to set up and provides a drop-in caching layer. ElastiCache is better if you need to cache data from multiple sources or if you need Redis features like sorted sets.
You can store small files (up to 400 KB per item) directly in DynamoDB as a binary attribute, but it is not best practice. For files, use S3 and store the S3 URL in DynamoDB.
The exam expects you to read a scenario about an application's data access patterns and correctly identify whether the solution should use DynamoDB, ElastiCache, or DocumentDB. The key differentiator is always the access pattern, not the data structure.
You've finished Non-Relational Database Design (DynamoDB, ElastiCache, DocumentDB). Continue through the DBS-C01 study guide to build a complete picture of the exam.
Done with this chapter?