Semester 6 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.

Build and defend a data-intensive service or investigation that forces you to make real choices about schema, indexing, transactions, replication, and failure handling.

The point is not to ship a large product. The point is to produce evidence that you can reason from the data model down to distributed tradeoffs.

---

Project Options

Choose one:

1. Build a small service with a relational core and explicit read/write workflows.
2. Build a database-focused lab repo that compares two storage or consistency approaches using the same domain.
3. Perform a deep redesign of an existing personal project whose current data model is weak, implicit, or fragile.

Your chosen scope must be small enough to finish, but rich enough to expose tradeoffs.

---

Required Project Components

1. Schema and Domain Model

Produce:

• a schema with keys, constraints, and clear naming
• a short explanation of why the model is shaped this way
• one identified place where denormalization is rejected or accepted deliberately

2. Query and Access Patterns

Produce:

• at least five meaningful queries or data-access paths
• one query-plan or execution-analysis note
• one example of a query or data path you improved and why

3. Storage and Indexing Decisions

Produce:

• an index plan tied to actual access patterns
• one note explaining write cost, read cost, and storage overhead
• one rejected indexing or storage idea and the reason it was rejected

4. Replication, Partitioning, or Availability Reasoning

You do not need to build a full distributed database. You do need to show that you understand the distributed consequences of your design.

Produce one of:

• a replication design note with lag and failover consequences
• a partitioning note with key choice, hotspot risk, and rebalancing concerns
• an architecture comparison showing why a single-node design is acceptable for current scope

5. Transaction and Consistency Analysis

Produce:

• one workflow where correctness matters
• the anomaly or failure you are protecting against
• the guarantee you actually need
• the cost of achieving that guarantee

6. Operational Evidence

Produce:

• basic observability notes: latency, errors, slow queries, lag, or contention
• security notes for credentials, least privilege, and sensitive data handling
• a rollback or migration note if the schema changes during the project

---

Suggested Project Shapes

• order and payment workflow
• booking and availability workflow
• inventory and reservation workflow
• event ingestion and query pipeline
• personal knowledge or learning tracker with concurrency-sensitive updates

Avoid domains that are trivial enough to hide the hard parts.

Deliverables

• a repo, notebook, or document set with reviewable history
• schema and query artifacts
• storage/index tradeoff notes
• one consistency or transaction analysis
• one replication, partitioning, or availability analysis
• a short final report titled What I Would Defend in Review

Final Report Structure

Your final report should answer:

1. What domain problem did you model?
2. What are the three most important data decisions you made?
3. What tradeoff hurt the most?
4. What failure mode worries you most?
5. What would you change next if this system had to support 10x more load or stricter correctness?

---

Self-Evaluation Rubric

Criterion	Strong evidence looks like
Modeling quality	Clear schema, justified constraints, and no accidental ambiguity in core entities
Query reasoning	Queries match the problem, and performance claims are tied to actual access paths
Storage and indexing judgment	Indexes and engine assumptions are explained in workload terms
Correctness reasoning	Transaction and consistency decisions map to real anomalies or user requirements
Distributed judgment	Replication, partitioning, or availability claims show realistic tradeoff awareness
Operational maturity	Security, observability, and migration notes exist and are concrete

Minimum Bar

The project is not complete if it contains code but no decision record. Semester 6 is about making data-system choices explicit and defensible.

Added Project Evidence

Your project must include a database evidence packet:

• requirements-to-entity extraction table
• ER diagram and relational schema
• normalization worksheet with functional dependencies and final normal form
• DDL and DML transcript for schema creation and seed data
• at least eight SQL queries covering joins, left joins, subqueries, grouping, counting, sorting, and updates
• EXPLAIN or EXPLAIN ANALYZE evidence for two important queries
• one relational-vs-document model tradeoff note
• one authorization or least-privilege note for database access

---

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

1. What is the smallest vertical slice that proves the project works?
2. Which requirement is most likely to be misunderstood by a reviewer?
3. What did you deliberately not build, and why?
4. 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:

• Answer key and solution outlines
• Rubric, passing standard, strong traits, and weak patterns