Module 5 · Lecture 20

Presentations II & Course Wrap-Up

The remaining teams present — then the whole arc pulled into one portable decision framework.

⏱ 90 minutes 🎤 5 teams · 10 + 3 min 🧭 Lectures 11–18 in one view

Today's Shape

Five presentations, then the synthesis

Clock	Segment	Detail
0–2	Opening	Timing change; peer forms out
02–15	Team 6	10 min + 3 min Q&A
15–28	Team 7	Set up during Team 6 Q&A
28–41	Team 8	On deck
41–54	Team 9	On deck
54–67	Team 10	On deck
67–72	Cross-team debrief	Patterns across all ten projects
72–84	Course synthesis	Families · framework · the compute trade · polyglot
84–90	Next steps & close	Certifications, the frontier, the closing argument

Worked example for a ten-team cohort. Slot length scales to the actual size — the format does not.

Timing · Changed

Shorter slots. Same rubric.

	Lecture 19	Today	What to do
Presentation	12 min	10 min	Cut two slides now. Merge the two Data slides; demo two questions, not three
Q&A	5 min	3 min	Expect two questions. Answer the one asked, not the one you rehearsed
Changeover	In slot	In slot	No slack at all — connect during the previous team's Q&A

Never cut these two

The recommendation and the limitations. The slide to lose is a second architecture view or a third dashboard panel. You had an extra week and two fewer minutes — the rubric does not adjust for either.

The grade is still for the decision the data supports, not the technology that produced it.

Debrief · 5 Minutes

Ten teams just ran ten experiments

Same brief, ten independent attempts. This is the fastest learning available in the module — answer all three aloud.

1 · Which modelling decision did the most work?

Across ten projects, which single embed-or-reference call — or which key design — bought the most, and why?

2 · Which recommendation would you fund?

One budget line. Whose project gets it? Defend it in one sentence.

3 · What did everybody get wrong?

A failure that recurred across teams is a property of the brief, not of any one team. Name it out loud.

Peer forms in before the synthesis. Scores written from memory are flatter and less useful than scores written live.

Synthesis · The Arc

Each family, and the question it answers best

Family	The business question it answers best	Why it wins there	Taught in
Relational	"Is this ledger correct, and can I prove it?"	Enforced schema, multi-table transactions, correctness first	L1–10
Document · MongoDB	"Our records have different shapes and analysts query any field."	Flexible shape, nested data stored as the app uses it	L12–16
Key-value · Redis	"What is happening right now, in under 10 ms?"	In-memory, O(1), purpose-built counting and ranking structures	L17–18
Column-family · Cassandra	"A million sensor readings a minute — where do they land?"	Linear write scale-out across nodes	L11
Graph · Neo4j	"Which claimants connect through shared addresses and garages?"	Traversal cost tracks the neighbourhood, not the dataset	L11

One dataset held it all: bdma.rides — modelled in L12, queried in L13, aggregated in L14, charted in L15–16, re-architected in L17–18.

Synthesis · The Asset

You will forget the syntax. Keep these five questions.

What is the access pattern? Write down the three most frequent queries before naming a technology.
What does a stale read cost? A rupee, or a slightly out-of-date view count?
How fast does the schema change? Monthly favours documents; untouched-for-three-years favours relational.
What is the realistic three-year volume? Honest growth, not ambitious growth.
Who operates it at 3 a.m.? The best database for a team that cannot run it is the wrong database.

How to use it in a meeting

You do not need to know the technology being proposed. Ask questions 1 and 2 and watch what happens. If nobody can state the three most frequent queries, the decision is being made on fashion — send it back.

First stated in Lecture 11, before you had the experience to see why each question mattered.

The Framework · Grounded

Where you actually met each question

Question	The moment in this course
1 · Access pattern	L12: embed vs reference was decided by whether rides and drivers are read together. L18: the whole key schema came from "the dashboard asks for today's totals every five seconds"
2 · Cost of staleness	L18: counters may lag the write by milliseconds — fine for an ops screen, unacceptable if the same number drove a driver payout
3 · Schema change	L13: adding `cancellation_reason` to some documents took no migration. On a 15-million-row SQL table it is a planned release with a rollback plan
4 · Three-year volume	15,000 documents fit M0 with room to spare. Most systems never leave single-server territory
5 · Who operates it	Every lab ran on Atlas precisely so none of you configured a replica set. That convenience is a real, recurring, usually-worth-it cost

The framework applies to technologies this course never mentioned. That is why it is the portable part.

Synthesis · The Central Trade

Every number is computed at one of two moments

Compute-on-read · MongoDB, L14

db.rides.aggregate([
  { $match: { booking_date:
      { $gte: ISODate("2024-01-01") } } },
  { $group: { _id: "$status",
              n: { $sum: 1 } } }
])

Work happens when someone asks. Any new question is free.

Compute-on-write · Redis, L18

INCR    rides:2024-06-14:total
INCR    rides:2024-06-14:status:completed
HINCRBY rides:2024-06-14:byhour 18 1

Work happens at ingest. Reads are O(1) — for questions you anticipated.

Not a MongoDB-vs-Redis question. The same trade recurs in warehouses, caches, materialised views, and every reporting system you will commission.

The Trade · In Full

What each choice costs you

	Compute-on-read	Compute-on-write
Work happens	At query time, every request	Once, at ingest
Read latency	Tens of ms to seconds, scaling with volume	Sub-millisecond, flat regardless of history
A new question	Free — new pipeline, existing data	Expensive — new key, write-path code, backfill
Fixing bad data	Fix documents; future queries correct themselves	Fix documents and recompute every derived counter
Storage	Raw data only	Raw data plus every pre-computed aggregate
Right for	Exploration, ad-hoc analysis, monthly reporting	Live dashboards, leaderboards, rate limits, counters
Fails when	Query volume is high and latency must be flat	Questions change faster than you can ship code

The rule: compute on read until latency or volume makes it untenable — then move only the specific, stable, high-traffic questions.

The Hybrid

What real systems actually do

Every ride is written to MongoDB as the system of record — complete, correctable, queryable on any field.
The same write path increments a handful of Redis counters for the five numbers the live dashboard needs.
The ops screen reads Redis and renders instantly.
Analysts run pipelines against MongoDB for anything the counters do not cover — which is most new questions.
A nightly job recomputes the counters from MongoDB, so drift is corrected within a day.

Step 5 is the one teams forget

Derived data drifts. With no scheduled path back to the source of truth, the dashboard slowly becomes confidently wrong — which is worse than being slow.

Pre-computing an aggregate is a commitment, not an optimisation. You are betting this question is still asked next year.

Synthesis · Polyglot

Several stores, each earning its place

Workload	Store	The property that decided it
Driver payouts and invoices	PostgreSQL	Multi-row transactions; a stale read costs real money
Ride records and analytics	MongoDB	Shape varies by product line; ad-hoc queries on any field
Live surge and ops dashboard	Redis	Sub-millisecond reads on a constantly refreshed page
Sensor and telemetry ingest	Cassandra	Write throughput beyond a single node
Fraud ring detection	Neo4j	Multi-hop traversal SQL cannot do at depth

The cost vendors omit

Every store is another thing to back up, monitor, patch, secure, capacity-plan and hire for — with consistency maintained by application code nobody enjoys writing. Two stores run well beat five run badly.

Correct when each store carries a genuinely different access pattern. Expensive when it is three databases doing one job because three teams had preferences.

Capability Audit · 1 of 2

Things you can now sit down and do

Capability	Concretely
Size an Atlas cluster	Estimate document size and count, project three-year growth, work out the working set, name the tier and defend it
Read an `explain()` plan	Spot `COLLSCAN` vs `IXSCAN`, compare `totalDocsExamined` to `nReturned`, say whether the index is used and whether it is the right one
Design a compound index	Equality → Sort → Range, and explain to an engineer why their field order is costing an in-memory sort
Make the embed/reference call	Decide on access pattern, document growth and update frequency — and say what would flip the answer
Write a multi-stage pipeline	`$match` early, then `$group`, `$unwind`, `$lookup`, `$sort`, `$project` — expensive stages seeing fewest documents, and a volume floor before any ranking by rate

Not "appreciate" or "be aware of". Do.

Capability Audit · 2 of 2

And what you can now push back on

Capability	Concretely
Design a Redis key schema	Consistent naming, the structure chosen for the property you need, deliberate TTLs, memory estimated before shipping
Build a dashboard that survives a stranger	Headline → driver → detail, units on every axis, denominators beside every percentage, no rate ranked without its volume
Turn a finding into a funded recommendation	Quantify the problem, propose the action, estimate return against cost, design the test that proves it
Challenge "our database needs no schema"	The schema moved into the application. Who validates it there? What happens the day two services disagree about a field's type?
Recognise when NoSQL is the wrong answer	Stable schema, single-server volume, transactional correctness, a team fluent in SQL → recommend PostgreSQL and be right

The last row matters most

A manager who can only recommend the new thing is no more useful than one who can only recommend the old thing. The value is in the discrimination.

Next Steps

Where to take this

Path	Covers	Why bother
MongoDB University — Associate Developer	CRUD, indexing, aggregation, modelling, drivers. Free courses, paid exam with student discounts	Roughly 70% is material you have already covered; the rest is drivers and deployment
MongoDB University — Associate DBA	Replica sets, sharding, backup, security, tuning	Take this instead if you are heading toward platform work
Redis University	RU101 for the data structures, then streams, search and JSON	Lecture 17 covered about a third of Redis. Streams are worth a weekend

The deepest remaining skill: the aggregation pipeline

$facet for multi-panel dashboards in one pass, $bucket for distributions, $graphLookup for hierarchies, $setWindowFields for running totals and moving averages. Almost every reporting requirement reduces to a pipeline.

Keep the site: Course Home · Assignments · Command Reference · Live Dashboard

The Frontier

Vector search moved into the document database

The most significant recent change in this space: Atlas Vector Search lets you store an embedding — a numeric array representing the meaning of text or an image — in an ordinary field alongside the rest of the document, index it, and query by semantic similarity rather than exact match.

Why it matters commercially

A retrieval-augmented system that recently needed a separate specialised vector database can now run on the store you already operate. It removes a system from the architecture.

The honest caveat

Dedicated vector databases remain faster at very large scale. Most organisations never reach that scale — so treat this as a strong default to evaluate, not a settled answer.

By question 5 of the framework, removing a system is usually worth more than any feature gained by adding one.

The Closing Argument

There is no best database

Only a best fit for a stated access pattern — and the manager's job is to force that pattern to be stated before the technology is chosen.

You will rarely write the migration. You will frequently be the person in the room who can insist the question is answered first.

The five questions outlive the syntax. Apply them to technologies this course never mentioned.
Every derived number is computed on read or on write. Move a question to write-time only once it is stable and expensive.
Pre-computation is a commitment. Give derived data a scheduled path back to the source of truth, or it drifts into being confidently wrong.
Polyglot persistence is normal and not free. Each store earns its place by carrying a different access pattern.
Recommending the boring option when it fits is a senior move, not a timid one.

Ask "what are the three queries this system will run most often?" before anyone names a product — and notice how often nobody has written them down. That gap is where your value is. Thank you.