Project 5 · Due Sun 6 July · after Session 10

Project 5: System Design Document

A complete design document for your capstone system that ties the whole course together.

What this is

The whole system, on a few pages.

The design doc is the artifact a staff engineer actually produces. It frames the problem, shows the design, and walks the key decisions, the failure modes, and the path the system takes as it grows.

💡 In plain English

This is the "show your work" document, the thing you'd genuinely circulate at work before building something big. It is not a novel. It is a clear map a teammate could pick up and follow.

Do this, in order

The steps.

1
Frame the problemWhat you're building, requirements, the non-goals you're explicitly not solving, and the key numbers.
2
Show the high-level designThe components and how data flows between them. One clear diagram beats three muddy ones.
3
Walk the key decisionsFold in or link your ADRs. The 2–4 calls that actually shaped the design, each with its trade-off.
4
Cover failure and operabilityWhat breaks, the blast radius, and the SLIs/SLOs you'd watch (Sessions 9 and 10).
5
Describe the evolutionWhat changes at 10× scale, and the trigger that tells you it's time.

The outline

Section by section.

Overview

one paragraph: what and why

Requirements + non-goals

functional, non-functional, and what you're NOT solving

Estimates

the bounding numbers (from Project 1)

Architecture

one clear diagram + the data flow in words

Key decisions

your ADRs, or 2–4 trade-offs with the "because"

Failure modes

what breaks · blast radius · fail open/closed

Observability

the SLIs/SLOs you'd watch

Evolution + open questions

the path at 10× · what you're still unsure of

How it's marked

What good looks like.

✓ Strong submission

Non-goals are stated, not just goals.
Decisions reference the trade-off, not only the choice.
There is a failure section and an observability section.
A teammate who wasn't in the room could follow it.

✕ Common mistakes

All happy path, no failure section.
A diagram with no reasoning attached.
No non-goals, so the scope quietly sprawls.
Decisions stated without the "because".

Wrapping up

Hand in the design doc.

Use the outline above; a few pages is plenty. It's the backbone of your Week 6 presentation, so write it so future-you can present from it.

Logistics

A few pages · the outline is your checklist · due Sun 6 July.

submit on Maven

Too big?

Depth over breadth. Cover one slice well rather than everything thinly.

scope it down

For the instructorHow to teach thisclick to open ▾

The talk-track for introducing and explaining this project to students, beat by beat.

1
Frame it as the real-world artifact: "Everything so far has been a part. This is the whole, the document you'd actually send round before building. It's the deliverable that most looks like the job."
2
The why: "A good design doc is how a staff engineer scales themselves, people build the right thing without you in every meeting." Stress it's a map, not an essay.
3
Walk the steps; the two that beginners drop are non-goals and the failure section. Insist on both: "Non-goals are how you stop the scope eating you. The failure section is how reviewers trust you."
4
Use the outline as a literal checklist they can copy. Tell them to link the ADRs rather than rewrite them, the doc and the ADRs are one body of work.
5
Rubric: the headline test is "could a teammate who wasn't in the room follow this?" Read the common mistakes as the inverse of that.
6
Logistics: a few pages, due July 6th, and it doubles as the script for their Week 6 talk, so writing it well now saves them later. Nudge over-scopers to go deep on one slice.