Overview

In the team project you design, build, measure, break and defend one system, from the first estimate to a load-tested deployment on Kubernetes. It is the course in miniature: every class adds a piece, every lab gives you a working example to adapt, and every milestone asks for evidence — a diagram, a passing check, a k6 report, a dashboard — not promises.

Team rules

• 2 to 3 students per team. Teams are registered by week 3 (form on Blackboard) with the chosen system option; changing option after week 5 needs the instructor's approval.
• One GitHub repository per team (monorepo recommended: services/, deploy/, load/, chaos/, docs/), with every member as a collaborator and the instructor and teaching assistant added.
• Documentation on GitHub Pages (MkDocs Material or Zensical), one section per milestone; the documentation template is a good start.
• Ownership table on the home page: each member owns at least one service and at least one cross-cutting area (e.g. observability, CI/CD, load testing, chaos, cost). Owners lead; everybody must understand everything.
• Every member commits with their own GitHub identity (git config user.name/user.email). Work done in pairs is marked with Co-authored-by: trailers.
• Milestones are tags: m1 … m9 on the commit to be graded, plus a short entry in the docs ("what we delivered, evidence, what is missing").

System options

Pick one option. Each one exercises the whole palette, but stresses a different part of it. Every option has two scales:

• Design target — the real-world scale, used in the design doc, the estimates and the cost report (you will not run it).
• Test target — a scaled-down load that your deployment (laptop with Docker Compose or kind/minikube, or a small cloud account) must sustain within the SLOs in the load-test campaign. If your environment cannot reach it, show the bottleneck with numbers and agree a new target with the instructor before week 14.

Mandatory components

Whatever the option, the system must have the components below (palette ids in parentheses — see the component catalog). The milestone where each one is first required is in the last column.

The hands-on labs give you a working version of almost every row: reuse them (and say so).

Deliverables

All deliverables live in the team repository and its GitHub Pages site:

1. Design doc + ADRs — design doc (M1, kept up to date until the end).
2. Running system — code, compose.yaml, Kubernetes manifests (or Helm/Kustomize), CI/CD workflows (milestones M2–M5).
3. Load-test campaign report — plan, k6 scripts, raw results, analysis (load-test campaign, M6).
4. Game day report — experiment plans, run sheet, findings and action items (game day, M7).
5. Cost report — design-target and actual costs, unit economics (cost report, M8).
6. Final presentation — slides, live demo, 3-minute video (presentation, M9).

Grading

Each deliverable receives a concept grade (I, D, C, B, A, with +) using the rubric on its page and the common level definitions; the project grade is the weighted average of the numeric equivalents. How the project grade enters the final grade is on the course page.

Documentation quality rubric

Timeline

Weeks are relative to the start of the semester; the dates are on the planning page. Each milestone has a 10-minute check-in in class during its week (demo + questions to any member) and is graded on the tag pushed by the deadline.

gantt
    title Project timeline (relative weeks)
    dateFormat  X
    axisFormat  W%s
    section Design
    M1 Design doc          :m1, 3, 5
    section Build
    M2 Core path           :m2, 5, 7
    M3 Scale & cache       :m3, 7, 9
    M4 Async & resilience  :m4, 9, 12
    M5 K8s + CI/CD         :m5, 12, 14
    section Prove
    M6 Load-test campaign  :m6, 14, 16
    M7 Game day            :m7, 16, 17
    section Communicate
    M8 Cost report         :m8, 17, 18
    M9 Presentation        :m9, 18, 20