Designing the Data Layer: DynamoDB
By the end of this lesson, you'll be able to:
- Identify this application's actual data-access patterns before choosing a database
- Justify DynamoDB for this scenario using access patterns and scale characteristics, not a generic "it scales" claim
- Explain at least one scenario where a relational database would have been the better-justified choice instead
Prerequisites: "Building the API Layer: API Gateway and Lambda"
Start from access patterns, not from a database's reputation
Module 5 already covered DynamoDB and the relational-vs-NoSQL decision in depth — this lesson doesn't repeat that ground. What it does is apply that reasoning to one specific, concrete case: this capstone's data. Two kinds of records need to persist for this scenario: a learner's progress through a course (which lessons are complete, for which learner, in which course), and a learner's certificate record once a course is completed.
The question that actually matters is not "which database scales better" — it's: how is this data actually going to be read and written? Progress lookups are almost always "give me this learner's progress in this course" — a lookup by a known learner-and-course key, not an open-ended query across every learner's data. Certificate lookups are the same shape: "does this learner have a certificate for this course."
Why DynamoDB fits this specific access pattern
Requirement: store and retrieve per-learner, per-course progress and certificate records at low, predictable latency as the number of learners grows.
Decision: use DynamoDB, with a key design built around learner ID and course ID.
Reason: the dominant access pattern here is a direct lookup by a known key, which is exactly what DynamoDB is built to serve efficiently and predictably at scale — not a generic claim that "DynamoDB scales," but a specific match between this data's access pattern and DynamoDB's key-based lookup model.
Alternative: a relational database (Module 5's RDS pattern), with a progress table joined to learners and courses tables.
Trade-off: DynamoDB makes ad-hoc, unplanned queries across attributes it wasn't designed around (for example, "list every learner who completed any course last month, sorted by name") considerably harder than a relational database's SQL would make the same query — a real cost accepted here because this application's actual, known access patterns don't need that kind of query.
When the relational alternative would have been the better-justified choice
This isn't a claim that DynamoDB is always the right answer. If this same scenario also needed a reporting feature — flexible, ad-hoc queries across learners, courses, and completions, with joins the application team can't fully predict in advance — a relational database would be the better-justified choice for that data, precisely because relational databases are built for flexible querying across related tables in ways a key-value/document model is not. A strong capstone submission is comfortable saying "this part of the data fits DynamoDB, and this other part would be better served by a relational database" rather than forcing one database to fit every need in the system.
Exercise
This application later adds an admin reporting feature: "show every learner who has completed at least two courses this month, along with which courses." Explain why this new requirement's access pattern is a worse fit for the DynamoDB table already storing progress records, and what kind of database would be better justified for this specific reporting need.
Show hint
Compare a lookup by a known key against a query that has to look across many learners' records using conditions decided at query time, not in advance.
Designing the Data Layer: DynamoDB Quiz
My Notes
Log in to keep private notes on this lesson.
Questions about this lesson
No questions yet — be the first to ask.
Log in to ask a question about this lesson.
Summary
This capstone's data layer stores per-learner course progress and certificate records — data that is almost always looked up by a known learner and course key rather than joined across many entities — which is exactly the kind of access pattern Module 5's relational-vs-NoSQL comparison identifies as a good fit for DynamoDB, provided the justification names the actual access pattern rather than repeating "DynamoDB because it scales."