Project Presentations II & Course Wrap-Up

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

Learning Objectives

• ✓ Present and defend a complete data project inside a thirteen-minute slot
• ✓ Map each database family covered to the class of business question it answers best
• ✓ Apply the five-question decision framework to a technology choice you have not seen before
• ✓ Articulate the compute-on-read versus compute-on-write trade and say which a given workload needs
• ✓ Justify a polyglot architecture — and recognise when it is complexity for its own sake
• ✓ Audit your own capability honestly against a concrete list of things a data-literate manager can do
• ✓ Choose a credible next step: a certification, a deeper skill, or the current frontier

Session Timeline

Continuing the worked example of a ten-team cohort: teams 6–10 present today. Slots are shorter than in Lecture 19 — thirteen minutes rather than seventeen — because the final twenty-three minutes belong to the synthesis. The lecturer adjusts slot length to the actual cohort size.

Section 1: Run Sheet for the Remaining Teams

Everything from Lecture 19 still applies — the rubric is unchanged, the peer form is unchanged, the demo-hygiene rules are unchanged. Three things differ.

Cross-Team Debrief — Five Minutes, Everyone

Before the synthesis, the room answers three questions aloud. These are not rhetorical; they are the fastest learning available in the whole module, because ten teams have just run ten independent experiments on the same brief.

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? If you had one budget line, whose project gets it? Say why in one sentence.
3. What did everybody get wrong? The failure that recurred across teams is the one worth naming out loud, because it is a property of the brief, not of any one team.

Section 2: The Arc of the Course

Ten sessions ago the question was "why would anyone use anything other than a relational database?" Everything since has been an answer to it. The table below is the course in one view: each family, the class of business question it answers best, and where you met it.

And the Skills Layered on Top

Section 3: The Decision Framework — The Most Portable Asset

You will forget the syntax. Within a year you will not remember the exact stage order of a pipeline or the argument order of ZADD, and that is fine — both are a search away. What should survive is the framework, because it is what you will actually be paid to apply. It is five questions, in this order, and it was first stated in Lecture 11 before you had the experience to see why each one matters.

Section 4: Compute-on-Read vs Compute-on-Write

If you remember one engineering idea from Lectures 14 to 18, make it this one. It is not a MongoDB-versus-Redis question — it recurs in data warehouses, caching layers, materialised views, and every reporting system you will ever commission.

Every derived number — a completion rate, a daily total, a leaderboard position — is computed at one of two moments: when someone asks for it, or when the underlying event happens. That choice determines your latency, your flexibility, and the cost of every new question.

The Same Number, Two Ways

In Lecture 14 you computed the completion rate with an aggregation pipeline: scan the matching documents, group, divide. The database did the work at the moment you asked, and the answer reflected every document written up to that instant.

// Compute-on-read — MongoDB, Lecture 14
db.rides.aggregate([
  { $match: { booking_date: { $gte: ISODate("2024-01-01") } } },
  { $group: { _id: "$status", n: { $sum: 1 } } }
])
// Cost paid: at query time, every time. Any new question is free.

In Lecture 18 you computed the same rate differently: every ride, as it was written, incremented a small set of Redis counters. The dashboard then performed no computation at all — it read four integers.

// Compute-on-write — Redis, Lecture 18
INCR  rides:2024-06-14:total
INCR  rides:2024-06-14:status:completed
HINCRBY rides:2024-06-14:byhour 18 1
// Cost paid: once per event. Reads are O(1) — and only for questions you anticipated.

The Hybrid, Which Is What Real Systems Do

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

Step 5 is the one teams forget, and it is what makes the architecture survivable. Derived data drifts. If there is no path back to the source of truth, the dashboard slowly becomes confidently wrong — which is worse than being slow.

Section 5: Polyglot Persistence — The Mature Answer

Lecture 11 ended on the claim that most large organisations run several databases. Having now built on two of them, you can see why that is engineering rather than indecision. A single ride-hailing business might reasonably run:

Section 6: What You Can Now Do

Not "appreciate" or "be aware of". These are things you can sit down and do, and they are the honest output of ten sessions.

Section 7: Where to Go Next

Certifications Worth the Time

The Deepest Remaining Skill — The Aggregation Pipeline

If you pursue one technical thing further, make it the aggregation framework. Lecture 14 covered the stages you need most often; the framework has roughly thirty more, and the ones that reward study are $facet (several independent aggregations over one pass of the data, which is how a multi-panel dashboard is built efficiently), $bucket and $bucketAuto for distribution analysis, $graphLookup for recursive hierarchies, and the window functions $setWindowFields added in version 5.0 for running totals and moving averages. It is the single highest-leverage skill in the MongoDB ecosystem, because almost every reporting requirement reduces to a pipeline.

The Current Frontier — Vector Search in Atlas

The most significant recent change in this space is that document databases have absorbed vector search. Atlas Vector Search lets you store an embedding — a numeric array representing the meaning of a piece of text or an image — in an ordinary field alongside the rest of the document, index it, and query by semantic similarity rather than by exact match. The practical consequence is that a retrieval-augmented generation system, which until recently required a separate specialised vector database alongside your operational one, can now run on the store you already operate. That matters commercially far more than it matters technically: it removes a system from the architecture, and by question 5 of the framework, removing a system is usually worth more than any feature you would gain by adding one. Treat it as a strong default to evaluate rather than a settled answer — the dedicated vector databases remain faster at very large scale, and the honest version of this recommendation is that most organisations never reach that scale.

Keep These Pages

This site stays up. The pieces you are most likely to come back to:

• Course Home — every lecture's notes and slides, in order
• Assignments — the briefs, including this capstone, with their rubrics
• Command Reference — the MongoDB and Redis commands used across the course, in one page
• Live Dashboard — the Lecture 18 Redis dashboard, as a reference implementation of compute-on-write
• Lecture 14 and Lecture 18 — the two halves of the trade in Section 4, worth re-reading together

Key Takeaways