Skip to main content

Defense: What Will Someone Ask, and What Is Your Answer

What This Concept Is​

The architecture defense is a short, live talk -- typically 5 minutes of prepared walkthrough + 5-10 minutes of Q&A -- in which you describe your capstone's architecture and answer probing questions. At the end of week 6 you give this to a grader, a mentor, or (in shape if not in form) any future interviewer who asks "walk me through a project." The talk has three parts:

  • Context (approximately60 seconds). What the capstone is, who it is for, what it proves. Show the C4 Context diagram.
  • Walkthrough (approximately2-3 minutes). Top-3 characteristics as the lens; the three ADRs as the decisions; the C4 Container + one Component diagram as the picture; one MVP happy-path trace as the proof.
  • Trade-offs (approximately60-90 seconds). What you picked, what you rejected, one thing you would do differently with more time, and your weakest point volunteered.

Then the Q&A. The goal is not for the questions to be easy; the goal is for them to be fielded gracefully, with every answer pointing to a concrete artifact -- an ADR, a diagram, a fitness function, a risk row.

This concept is marked SUPPORTING because it does not change what you build -- but it changes whether what you built is understood and rewarded. Unsupported does not mean unimportant; it means orthogonal to the code.

An often-overlooked property of the defense: it is a diagnostic tool all semester long, not just a performance in week 6. Every Friday rehearsal exposes a hole in the design doc while there is still time to fix it. If you cannot say out loud why you picked Postgres, your ADR-002 is not finished.

Why It Matters Here (In the Capstone)​

The defense is the moment your architecture is evaluated by a human. Everything else in this module -- diagrams, ADRs, fitness functions, glossary, risk register -- exists to make this moment short and credible. An engineer who gives a clean 5-minute defense of an average architecture scores higher than one who builds a great architecture and stumbles through the defense. The defense compresses a semester's artifacts into the grader's actual decision window.

The second reason this matters in the capstone specifically: the defense doubles as your rehearsal for every future behavioral interview question of the form "walk me through a project." The structure here -- context, top-3 drivers, decisions tied to characteristics, trade-offs volunteered -- is the exact structure senior-level interviews reward. You are building muscle memory for the rest of your career.

The third reason: the act of preparing the defense sharpens the capstone itself. When you try to say "I chose Postgres because..." and the sentence won't finish, you have discovered that ADR-002 is aspirational. When you try to say "my top 3 characteristics are..." and you list four, you have discovered that concept 07 wasn't actually done. Every rehearsal is a free code review.

Concrete Example(s) -- from a real capstone​

Example A -- inventory service, anticipated questions and model answers:

  • Q: "Why a modular monolith and not services?" A: "My top-3 are correctness, operability, and offline availability. Services would cost a week on inter-process plumbing I don't have; a plain monolith hides the scan-core / reports boundary that is the defensible DDD move here. Modular monolith keeps both. ADR-001."
  • Q: "Why Postgres? Why not SQLite?" A: "Correctness under concurrent scans needs real transactions across sessions; SQLite's single-writer model would block the API. Postgres's unique-constraint-based idempotency is what makes the scan-idempotency fitness function pass. ADR-002."
  • Q: "What happens if the DB goes down during a scan?" A: "Scans buffer on the PWA with the same idempotency key. On reconnect, the server re-applies them; the unique constraint makes replay safe. I validated this with a kill-and-replay test in week 2 -- risk row #1."
  • Q: "What would you do differently?" A: "I'd move the reconciliation job behind a proper queue. It's in-process today, which is fine at this scale but would be the first thing I'd extract if the warehouse grew past two staff."
  • Q: "Where is your weakest point?" A: "Concurrent reservations under very high contention (thousands of QPS on one SKU) aren't characterized. I don't think it matters for a solo warehouse, but I can't prove it yet."

Each answer is short, honest, and tied to an artifact (ADR / fitness function / risk row / test). The defense is not rhetorical performance; it is a guided tour of your written documents.

Example B -- ticketing platform, 5-minute structured walkthrough:

  • 0:00-0:45. "A student-club event ticketing platform: buy -> QR -> door-scan, strict no-oversell. Context diagram: buyer, organizer, door-scan PWA, SMTP. Capstone is a single box."
  • 0:45-2:30. "Top-3: correctness (no oversell), operability, door-scan availability. Container diagram: API + Postgres + SMTP. Style: modular monolith because 6 weeks / solo / strict invariant lives in one process. ADR-001."
  • 2:30-3:45. "Component diagram of the API: reservations is the core; QR is supporting; billing is generic. Walking happy path: POST /events/X/reserve -> reservations -> DB with a unique (event, seat) constraint -> success. Fitness function: 100 concurrent reserve calls on a 1-seat tier produce exactly 1 success."
  • 3:45-4:30. "ADR-002: Postgres with unique constraints -- chose it because the correctness driver is impossible in eventually-consistent stores at this scale. ADR-003: single region managed DB -- chose it because operability beats multi-region at solo scale; multi-region is a non-goal."
  • 4:30-5:00. "One thing I'd change: door-scan retry logic is optimistic; under intermittent wifi it can stall. Weakest point: I didn't stress-test SMTP failures; emails might silently drop under a backlog."

Example C -- finance aggregator, category-by-category probing prep:

CategoryQuestionPointer
Why this decision?Why encrypt locally, not use a cloud secret store?ADR-003 + Privacy driver (#2)
What if this fails?What if the user loses the passphrase?Risk row #4; UX warns; no recovery; documented
Why not the alternative?Why not SQLite + SQLCipher?Considered; rejected because I wanted explicit encrypt/decrypt boundary (testable), and Postgres is irrelevant (local-only)
What did you learn?What surprised you?The rules engine was the real core, not the CSV importer -- I reclassified subdomains in week 3

Common Confusion / Misconceptions​

  • "I will prepare the defense the day before." You will not have the emotional capacity to rehearse the day before; you will re-read the design doc and feel prepared. Reading is not rehearsing. Speaking out loud is rehearsing. Start in week 1.
  • "I should hide my weak points." You should not. The grader will find them; owning a weak point reads as maturity. Every real system has weak points; volunteering yours pre-empts a harsher framing.
  • "Good answers are long." Good answers are short, tied to artifacts, and end. The longer you talk, the less certain you sound. If the grader wants more, they will ask.
  • "A defense where the grader asks nothing hard means I succeeded." No -- it means the design was too timid, or the grader lost interest. Hard questions gracefully answered is the signal of success.

Structuring the 5-Minute Walkthrough​

Concretely, five minutes is ~250-300 words of actual speech. Less than one page. It should feel short to you while rehearsing. The time budget:

  • 0:00-0:45 -- Context. One sentence: what. One sentence: who. One sentence: what it proves. Show Context diagram.
  • 0:45-2:30 -- Container diagram + style choice + top-3 characteristics as the reason. Name the core subdomain.
  • 2:30-3:45 -- One Component diagram. Trace the MVP happy path through it.
  • 3:45-4:30 -- Two ADRs: the most interesting and the one most likely to be challenged. One sentence each.
  • 4:30-5:00 -- One weakness volunteered. One "I'd do differently." End on time.

Categories of Probing Questions​

Expect questions from four categories. Prepare at least two in each category:

  • Why this decision? -- Tied to an ADR or the top-3 characteristics.
  • What if this fails? -- Tied to the risk register and fitness functions.
  • Why not the alternative? -- The "rejected option" column of your architecture section.
  • What did you learn? -- The honest one. Tie it to a specific moment in the build, not to a platitude.

How To Use It (In Your Capstone)​

  1. End of week 1, write 10 anticipated questions (at least two per category) with 2-3 sentence answers. Each answer points to a named artifact.
  2. Commit library/raw/defense.md alongside the design doc. This is part of your capstone deliverable, not an afterthought.
  3. Rehearse weekly. Every Friday, pick a random question and answer it out loud, from memory. If you cannot, go fix the underlying artifact the same afternoon.
  4. At week 6, do a single recorded dry-run of the full 5 minutes. Watch it back exactly once. Fix the one worst sentence.
  5. Volunteer your weakness in the walkthrough -- do not wait to be asked. Owning it costs you 15 seconds and buys you credibility.
  6. Do not script word-for-word. Script the structure, bullet-point the content, speak naturally. A memorized script collapses under even one unexpected question.
  7. Close on time. Ending at 4:55 with the "I'd do differently" line hits harder than ending at 7:20 because you over-explained ADR-002.

See also (integrative)​

Defense builds on communication disciplines from S7 M01 and S8 M05 and the review-facilitation discipline from S7 M05.

External references (curation-validated this session):

Check Yourself​

  1. Can you name two questions you anticipate from each of the four categories, and point to the artifact that backs each answer?
  2. Why is "I wouldn't change anything" a bad answer to "what would you do differently?"
  3. How long is a good walkthrough -- and how many words of speech is that, roughly?
  4. Can you volunteer your weakest point in one sentence without apologizing?
  5. When do you start rehearsing -- and how often?

Mini Drill or Application (Capstone-scoped)​

  • Drill 1 (30 min, end of week 1). Draft library/raw/defense.md: 10 questions, 2-3 sentence answers, each tied to a specific artifact. Commit.
  • Drill 2 (5 min weekly). Pick one random question from the list. Answer out loud, from memory. Where you stumble, go fix the artifact that afternoon.
  • Drill 3 (10 min, end of week 3). Write the 5-minute walkthrough as a structured bullet outline (not prose). Time yourself reading it: <= 5 minutes.
  • Drill 4 (20 min, week 5). Record one dry-run. Watch exactly once. Fix the single worst sentence. Do not re-record endlessly.
  • Drill 5 (5 min, week 6 morning). Rehearse just the opening 60 seconds three times. The opening sets tempo for the rest.

Source Backbone​

Capstone design applies earlier architecture and domain material. These books are the source backbone for the decisions in this module.