Semester 8 Project
Required Output Classification
| Required output | Classification | Public/private guidance |
|---|---|---|
| Runnable project implementation and repository structure | Portfolio candidate | Polish the public repo only after tests pass, secrets are removed, and setup steps work from a clean checkout. |
| README with setup, inspection, verification instructions, and known limitations | Portfolio candidate | Make this public-facing if the project is safe to share; keep internal coursework notes in a private evidence folder. |
| Tests, traces, proofs, diagrams, benchmark outputs, or review notes required by the brief | Checkpoint evidence | Keep raw logs, benchmark runs, and reviewer comments private by default; publish summarized or reproducible versions when useful. |
| ADRs, design memos, runbooks, benchmark reports, and other high-effort engineering writeups | Portfolio candidate | These are worth polishing publicly when they tell a clear tradeoff story; otherwise keep them as private coursework evidence. |
| Final reflection, retrospective, or carry-forward notes | Checkpoint evidence | Keep candid self-assessment private unless rewritten as a concise public learning note. |
Design and document RideHail Dispatch, a regional ride-hailing platform that matches riders with nearby drivers, runs the trip lifecycle, and settles payments at scale. This project is not an implementation brief; it is a design packet: a large design document, supporting case studies, a set of ADRs, capacity estimates, and a staff-level strategy memo that another senior engineer would review.
Objective
Tie together system design methodology, service decomposition, event-driven patterns, scale reasoning, and leadership artifacts around a single realistic product. The deliverable is written work you could place in a portfolio, use in a staff-level interview, or hand to a real team as a starting point for implementation. The grading standard is not polish; it is whether another engineer could meaningfully review and challenge your choices.
Deliverables
- Architecture case studies -- Two short case studies of public systems that share RideHail's shape: one real-time dispatch or marketplace platform (e.g., Uber / Lyft / DoorDash engineering blogs) and one real-time location or logistics system. For each, infer the requirements and drivers, sketch the candidate architecture, and list three decisions you agree with and three you would challenge, with reasoning beyond preference.
- Large-scale design document -- An end-to-end design doc for RideHail Dispatch covering functional requirements (rider request, driver matching, trip lifecycle, pricing, payment, notification), non-functional targets (P95 match latency under 5 s at regional peak, 99.9% availability for the ride-request path, sub-second driver-location ingestion), C4-level diagrams (context, container, component for the matching service), service boundaries, data ownership, API contracts, event flows with at least one saga, and capacity estimates for a target of 5 million daily trips across three regions.
- Technical strategy memo -- A 2-3 page memo aimed at an engineering VP making the call: should RideHail continue on a modular monolith for the next 12 months, or invest now in a microservice split? Use Rumelt's structure -- diagnosis, guiding policy, coherent action -- and name the rejected alternative, the risks, the measurable success signals, and the six-month milestones.
Constraints & Rubric
Time-box the full project to the 8-week semester, with roughly one cluster of work every two weeks alongside the modules. Depth expectations: each diagram must be tied to a named driver or quality scenario, each ADR must name the rejected alternative and its cost, and each capacity estimate must show its arithmetic. Self-grade each deliverable on a 1-5 scale using the rows below; any deliverable below 3 must be revised before you treat the semester as complete.
| Deliverable | Done when... | Self-score (1--5) |
|---|---|---|
| Case studies | Each study has inferred requirements, drivers, an architecture sketch, and six explicit takeaways (three agreements, three challenges), each with reasoning grounded in mechanics or constraints rather than preference. | |
| Design doc | Covers framing, estimates with arithmetic, high-level design, a deep dive for the matching hot path, data ownership and event flows, failure and scale analysis, and a trade-off log; another engineer could hand it to a team and they could start implementing. | |
| Strategy memo | Opens with a one-sentence diagnosis, names a guiding policy, lists 3-5 coherent actions with owners and dates, calls out at least one rejected alternative, and ends with a measurable success signal a VP could hold the team to. |
Suggested Timeline (8 weeks)
- Week 76 (M1): Pick and frame the first case study; produce framing + estimates for RideHail (functional requirements, three non-functional targets with numbers, constraints, ranked hard parts).
- Week 77 (M1): High-level design for RideHail; deep dive on the matching hot path; first stress-test pass (10x, kill-every-box).
- Week 78 (M2): Second case study; service decomposition for RideHail (extraction order, data moves, module-vs-service ADR).
- Week 79 (M2): Contracts, data ownership diagrams, synchronous vs async communication choices; first ADR set.
- Week 80 (M3): Event catalog, driver-location ingestion pipeline, trip-lifecycle events; choose broker style (log-based vs queue) with reasoning.
- Week 81 (M3): Saga for trip-completion + payment settlement; CQRS read model for rider-facing trip view; compensating actions documented.
- Week 82 (M4 + M5): Capacity math, SLIs/SLOs, error-budget policy, incident runbook fragment; first draft of the strategy memo (diagnosis / guiding policy / coherent action).
- Week 83: Full design-doc review against the rubric, ADR cleanup, strategy memo polish, and integration with cumulative review and exam prep.
Cross-Track Integration
- Testing (L4): Contract tests between the matching, trips, and payments services; a synthetic load-generator plan that exercises the dispatch hot path at 1x, 3x, and 10x target QPS; a failure-injection checklist per deployed service (broker down, DB leader swap, region loss).
- Git (L4): Design doc, ADRs, and strategy memo all live in the project repo under
/docs; each is opened as a pull request and reviewed with the same rigor as code; ADR numbering is monotonic and each ADR links to the PRs that implement or supersede it. - Security (L4): Threat model for trust boundaries between riders, drivers, payments, and third-party providers; a data-classification matrix (PII, payment, precise location) with controls per class; at least one architecture-level risk documented as its own ADR with the chosen mitigation and residual risk.
- Observability (L3): Golden SLIs per service (match latency, trip-state transition error rate, payment-auth success rate, location-ingest lag), a dashboard sketch that shows cause-and-effect across services, and the minimum set of trace fields an on-call responder would need at 03:00 to triage a bad match-latency alert.
Submission Checklist
- Diagrams are legible, consistent, and keyed to a single notation (C4 or an explicit equivalent legend).
- Every major decision is written as "A over B because C", with the rejected alternative and its cost stated explicitly.
- The strategy memo ends with a dated recommendation, named owners for each action, and the metric that will prove it worked.
Production-Style Project Brief
Use this project as a reviewable engineering brief, not only a completion exercise.
Problem statement
Write a one-paragraph statement covering the user, the problem, the constraint, and the outcome this project is meant to produce.
Required evidence
- working artifact or reproducible deliverable
- README with setup, inspection, and verification instructions
- tests, traces, proofs, diagrams, benchmark output, or review notes appropriate to the semester
- decision log with at least three meaningful tradeoffs
- known limitations section with explicit scope cuts
Review questions
- What is the smallest vertical slice that proves the project works?
- Which requirement is most likely to be misunderstood by a reviewer?
- What did you deliberately not build, and why?
- What evidence would convince someone else that the result is correct?
Done means
The project is done only when another technical reader can inspect the artifact, run or review the verification evidence, and understand the tradeoffs without a live explanation.
Weekly Project Milestones
Use these milestones to keep the project from becoming a last-week scramble.
| Milestone | Focus | Evidence |
|---|---|---|
| Start | Scope the smallest useful slice | problem statement, non-goals, first task list |
| Early build | Produce a walking version | runnable skeleton, first test, first committed artifact |
| Middle | Add the hard part | implementation note, trace/proof/benchmark/design decision |
| Review | Stress the weak point | failure case, debugging note, peer/self review, correction commit |
| Finish | Package for inspection | README, verification instructions, known limitations, reflection |
Answer-Quality Examples
| Quality | What it sounds like |
|---|---|
| Weak | "I built it because the module asked for it." |
| Acceptable | "It works for the required examples and I can explain the main idea." |
| Strong | "Here is the tradeoff I chose, the evidence that supports it, and the case where it would fail." |
| Portfolio-ready | "A reviewer can inspect the artifact, rerun the checks, and understand why this solution fits this semester's goals." |
Future Capstone Connection
Before closing this project, write two sentences on how it could help the final capstone: one reusable technical skill and one artifact habit to preserve.
Calibration Materials
Use these learner-visible calibration materials before self-grading or requesting review: