The capstone brief, the rubric you are marked against, and the run sheet for the day.
This is the brief you build against: the deliverable, the five mandatory requirements, the dataset guidance, and the rubric you will be marked by.
This is the run sheet projected while the session runs: timing rules, running order, the peer-evaluation form, and the hard stop.
Eight lectures took you from "why not relational?" to a live Redis dashboard. This is where you prove you can use it on a problem nobody handed you.
Each of those four words is a place marks are lost.
| Word | Demands | Common failure |
|---|---|---|
| Real | Data someone generated by doing something | 200 synthetic rows with no missing values |
| Model | A deliberate shape decision | A CSV dumped into one flat collection |
| Dashboard | A view a named person opens on Monday | Charts the tool offered |
| Recommendation | An action, an owner, a number | "Worth looking into further" |
You may use bdma.rides. You already know its answers: 62.29% completion, 17.99% driver cancellations, โน13,33,539 estimated leak, 18:00 the busiest hour at 1,373 bookings, and the worst failure rate among the hours that carry volume at 17:00 โ 39.92% on 1,062. Re-finding those proves you can follow instructions.
| Source | What you get | Watch for |
|---|---|---|
| Kaggle | Documented retail, logistics, churn, review data | Over-mined headline sets โ pick one with few public notebooks |
| data.gov.in | Crop prices, rail punctuality, pollution, census | Column names change between annual files โ the cleaning story earns marks |
| RBI / NSE | Payments, credit, bhavcopy, delivery percentages | Mostly time series โ strong for Redis, weak for documents unless enriched |
| Your workplace | A dataset with a real decision-maker attached | Clear it first. Anonymise. Never commit the raw file |
| # | Requirement | Evidence we look for |
|---|---|---|
| 1 | Data in Atlas or Redis โ or both, with the split justified | Counts, load script, records rejected and why |
| 2 | One non-trivial aggregation pipeline or Redis structure | More than $match + $group; the business question stated above the code |
| 3 | An index with explain() before/after, or a documented key schema | totalDocsExamined and executionTimeMillis, both runs โ or keys, structures, TTLs |
| 4 | A working dashboard | Atlas Charts or the L18 Redis + Node pattern โ neither scores higher by default |
| 5 | The model decision written down and justified | A slide naming the alternative you rejected |
| Stage | Slides | Min | What it must land |
|---|---|---|---|
| Problem | 1 | 1 | Whose problem, what it costs today, who would act |
| Data & why non-relational | 2 | 2 | The specific property that made a table a poor fit |
| Model & architecture | 2 | 2 | Embed vs reference, or key schema โ and the rejected alternative |
| Dashboard demo | 3 | 3.5 | Three questions answered live โ not a tour of every chart |
| Findings | 2 | 2 | Two or three numbers, with their denominators |
| Recommendation | 1 | 1 | One action, one owner, one expected impact |
| Limitations | 1 | 0.5 | What the data cannot tell you โ before the panel finds it |
A simple dashboard with three clear charts and one sharp, quantified recommendation beats an elaborate one that ends at "here are some charts". Every time. Without exception.
Sharding, change streams, a custom React front end, a vector index โ none of these earn marks on their own. They earn marks only when they are the reason you could answer a question you otherwise could not.
Finish this sentence: "We built this so that the business could decide ______." If you can't, cut it and spend the time on the recommendation.
"Among the hours that carry real volume, driver-side failure is worst at 17:00 โ 39.92% on 1,062 bookings, against the 18:00 peak's 37.14% on 1,373 โ worth an estimated โน13.3 lakh a year. We recommend a โน40 surge incentive on 16:00โ18:00 airport pickups, capped at 300 rides a day. If it converts a third of those cancellations it recovers about โน4.4 lakh against โน1.3 lakh of incentive spend. We would run it four weeks in one zone first."
"Cancellations are a significant issue, particularly in the evening. The business should investigate driver behaviour during peak hours and consider appropriate interventions."
| Criterion | Marks | Adequate | Excellent |
|---|---|---|---|
| Problem framing & relevance | 15 | A plausible problem, loosely related data | Named decision-maker, cost of status quo, narrow enough for data to settle |
| Modelling & justification | 20 | A model that works, choice described | Rejected alternative named; growth, cardinality and update frequency considered |
| Technical execution | 25 | Pipeline runs, index exists, dashboard connects | ESR obeyed, explain() quantified, Redis structures chosen for properties not familiarity |
| Dashboard design | 20 | Charts render and are labelled | Headline โ driver โ detail; units on axes; readable with no narration |
| Insight & recommendation | 15 | Accurate findings, reasonable suggestion | Costed, owned, quantified, testable; limitations volunteered |
| Presentation & Q&A | 5 | Near time, questions answered | Inside 12:00 with demo intact; "we don't know, here's how we'd find out" |
| Failure | In the room | Fix |
|---|---|---|
| No recommendation | Twelve minutes of charts, then "thank you" | Write the recommendation slide first. If you can't draft it, you don't have a project |
| Vanity metrics | A ticking total nobody can act on | If this number doubled tomorrow, who does what differently? Nobody โ cut the chart |
| Unlabelled axes | y-axis to 4,000 โ rides? rupees? minutes? | Units on every axis; denominator beside every percentage: "17.99% (2,699 of 15,000)" |
| Rate with no volume floor | "Our worst hour is 03:00 at 43.48%" โ on 46 bookings | Apply a volume floor before ranking; show the denominator beside every rate |
| Causation from correlation | "Failures are worst at 17:00, so drivers avoid the evening" | Say "associated with", name what you can't rule out, propose the test |
| A borrowed model | New data forced into the rides shape; sub-documents nobody queries | Re-derive from your access pattern |
| Demo with no fallback | Four minutes watching a spinner | Screenshots in the deck + a recording. Switch in 15 seconds |
| Hour | Failure rate | Bookings | What it actually is |
|---|---|---|---|
| 03:00 | 43.48% | 46 | Noise โ two more failures moves this four points |
| 07:00 | 41.60% | 637 | Suggestive, still thin for a costed intervention |
| 16:00 | 40.45% | 764 | The shoulder of the real problem |
| 17:00 | 39.92% | 1,062 | The finding โ worst rate among hours carrying volume |
| 18:00 | 37.14% | 1,373 | Busiest hour of the day โ lower rate on more rides |
"03:00 is our worst hour." Forty-six bookings. No intervention can reach them.
"The worst failure rate among hours that carry volume is 17:00 at 39.92% โ above the 18:00 peak's 37.14%, though 18:00 takes 1,373 bookings to 17:00's 1,062."
{ $group: { _id: { $hour: "$booking_datetime" }, bookings: { $sum: 1 }, failed: { $sum: ... } } },
{ $match: { bookings: { $gte: 1000 } } }, // <-- the volume floor, stated on the slide
{ $addFields: { failure_rate: { $divide: ["$failed", "$bookings"] } } },
{ $sort: { failure_rate: -1 } }
Warning at 11:00. Stop at 12:00 โ mid-sentence if necessary. Content not reached is content not marked.
Questions go to the whole team. The chair may direct one at a named member. Everyone needs the model and the headline numbers.
The next team connects and tests during the previous team's Q&A. Changeover is not slot time.
Score during the presentation, not from memory at the end. No interruptions during the twelve minutes โ write the question down.
| Slot | Clock | Team | Status |
|---|---|---|---|
| โ | 0โ4 | Opening & ground rules | Forms out |
| 1 | 04โ21 | Team 1 | Presenting |
| 2 | 21โ38 | Team 2 | Set up during Team 1 Q&A |
| 3 | 38โ55 | Team 3 | On deck |
| 4 | 55โ72 | Team 4 | On deck |
| 5 | 72โ89 | Team 5 | On deck |
| โ | 89โ90 | Close ยท L20 order confirmed | Forms in |
| Dimension | The question you are answering | Score 1 | Score 5 |
|---|---|---|---|
| Clarity of the problem | Did you know, within 90 seconds, whose problem this was and why it mattered? | Still unclear at the end | Obvious immediately, never lost |
| Credibility of the analysis | Do you believe the numbers, and would they survive a sceptical question? | Unsupported or inconsistent | Sourced, denominated, defended |
| Strength of the recommendation | Could a manager act on this on Monday? | Vague or absent | Specific, costed, owned, testable |
The examiner marks against the rubric; peer data corroborates. Scoring your friends uniformly 5 helps nobody and is visible in the distribution.
No connection strings, passwords or API keys on a slide, in a screenshot, or in a public repo. Blur the host in Atlas captures. Credentials shown to forty people get rotated that evening.