Skip to main content

Module Quiz

These are capstone-applied, scenario-based questions. Recall alone will not pass them. The right answer, in most cases, is "it depends -- here is what I would ask, here is what I would cut, here is what I would write down."

Complete after all concept and practice pages.

Current Module Questions​

Question 1: Problem right-sizing​

A student proposes: "A distributed, event-sourced, CQRS-based grocery list for a family of four." Name three signals that this capstone is wrongly scoped, and one question you would ask the student to help them re-scope.

Answer: Signals: (1) the architectural complexity (event-sourced, CQRS, distributed) has no driver -- a grocery list has no consistency or scale requirements that demand any of those; (2) the user (family of four) does not have the pain those capabilities address; (3) the stack chose the problem, not the other way around. Question: "what is the one user pain this solves that a shared Google Doc does not?" If there is no answer, the capstone is indefensible.

Question 2: Risk register under pressure​

You are at the end of week 2. Your #1 risk was "I have never deployed WebSockets to my target cloud." You deployed them successfully in week 1. Your load test reveals a new risk: broadcast latency spikes to 2 seconds when a single client has a slow network. What do you do to the risk register, and does your architecture need to change?

Answer: Close the old row (deployment risk is resolved). Add the new row with mitigation: "decouple broadcast from the slow client via a per-client outbound queue with bounded depth." Mark it architecturally significant. The architecture change is small (a queue per socket) but warrants an ADR amendment or a short new ADR because it introduces a new component in the Component-level C4 diagram.

Question 3: MVP versus feature creep​

In week 3, you realize that adding voting (not in your MVP non-goals) would take "only two days." Your vertical slice is not yet deployed to staging. Given the scope-cut rules you wrote in week 1, what do you do?

Answer: Do not add voting. The rule is simple: MVP is vertical-slice end-to-end, and voting is not in the slice. Two days of drift against the schedule compounds -- week 4 you will be two days behind, which triggers your first scope-cut rule. The correct move is to finish and deploy the vertical slice, then reconsider voting only after staging is green.

Question 4: EventStorming hot spot to architecture​

During solo EventStorming, you mark "note broadcast to peers" as a hot spot because you do not know what happens when a peer is offline. You carry this into Cluster 3. How does this hot spot shape your characteristics ranking and your style decision?

Answer: The hot spot promotes "real-time responsiveness with graceful degradation" into the characteristics conversation. Depending on user tolerance, it may or may not make top-3 -- but it must be addressed. On the style decision: if you pick services, each service needs its own broadcast logic or a shared bus; if modular monolith, broadcast is one module with one clear seam. The hot spot is evidence for the modular-monolith choice at capstone scale.

Question 5: Subdomain misclassification​

A student classifies "authentication" as core for a capstone that is a personal knowledge base. Why is this almost certainly wrong, and what does it predict about the capstone's outcome if uncorrected?

Answer: Core means "the reason the capstone exists." The reason a personal knowledge base exists is the knowledge management, not auth. Classifying auth as core predicts the student will spend weeks on OAuth flows and password reset, and arrive at week 5 with auth but no knowledge base. Correct: auth is generic -- buy a managed solution or skip it for MVP by accepting a single-user local install.

Question 6: Ubiquitous language breakdown​

In week 3 you notice the design doc uses "retro" and the database schema uses "meeting" for the same entity. Nothing is broken. What do you do, and why does it matter at capstone scale?

Answer: Pick the glossary term (retro). Rename everywhere -- DB column, migration, queries, design doc references if wrong. It matters because drift compounds: by week 5 you will have three names, and the grader will not be able to follow the code. Renaming in week 3 is five minutes; renaming in week 5 is a day and a bug risk.

Question 7: Top-3 characteristics under a changed constraint​

You planned top-3 as operability, simplicity, real-time responsiveness. In week 2, you discover your target cloud free tier does not support the WebSockets needed for real-time. What do you do to the characteristics list, and what is the downstream effect?

Answer: Do not silently cut "real-time responsiveness." Options: (a) change providers (affects ADR-003); (b) relax the characteristic from p95 500ms to "near real-time via short polling" and update the fitness function and design doc; (c) accept that real-time responsiveness leaves top-3 and is replaced -- but state what replaces it. In all three cases the characteristics file is updated and an ADR is written or amended. Silently ignoring the change is the bad path.

Question 8: Style choice under honest constraints​

A student picks microservices for a solo 6-week capstone "to demonstrate modern architecture." They have a single core subdomain and no scale requirements. Critique the decision.

Answer: Services are the wrong style: (1) no driver -- no top-3 characteristic is served by the choice; (2) the cost (service discovery, inter-service auth, distributed tracing, local dev setup) will consume a week that the student does not have; (3) one core subdomain does not need service-level isolation; (4) the defense will be weak -- "to demonstrate modern architecture" is not a driver. Modular monolith is the correct default; the student should write ADR-001 with monolith, modular monolith, and services as alternatives, and pick modular monolith with an honest justification.

Question 9: Fitness function versus unit test​

Your design doc claims: "the export module does not depend on the realtime module." Describe the fitness function that enforces this and explain why a unit test on the export module is insufficient.

Answer: A fitness function in tests/arch/ inspects the import graph of src/export/ and fails if any file there imports from src/realtime/. A unit test on the export module tests behavior, not imports -- a careless future commit that pulls in a realtime helper would pass all unit tests silently while violating the architecture. The fitness function is the check that cannot be silently violated.

Question 10: ADR under deadline pressure​

It is week 4. You are behind schedule. You discover you need to swap your datastore. You are tempted to just change the code. What is the minimum ADR discipline you must maintain, and why?

Answer: Supersede ADR-002 with a new ADR (call it ADR-004) that states the new decision with status Accepted, a Context that names the driver for the swap (what broke, what was learned), Decision, Consequences. Mark ADR-002 "Superseded by ADR-004." This takes 15 minutes. Without it, the defense in week 6 is indefensible -- the grader sees two different datastores implied and written, and you cannot explain why. Cutting the ADR is exactly the wrong cut.

Question 11: C4 level selection​

Your capstone is a modular monolith with one datastore. A student reviewer says "you need Component diagrams for every container." Why is that wrong at capstone scale?

Answer: Component diagrams add signal only for non-trivial containers. The datastore (Postgres) does not have "components" you designed; the browser SPA is a client of the core. Only the core subdomain's internals genuinely need Component-level decomposition, because that is the module whose shape the grader will probe. Drawing Component for everything adds visual noise and implies the author does not understand what the level is for.

Question 12: Schedule anti-pattern detection​

It is Friday of week 2. Your commit history shows the last two weeks of work was on the UI and the logging setup. No end-to-end request has run. Which anti-pattern is this, and what is the recovery move?

Answer: Horizontal building. The recovery move is to stop UI and logging work, assemble a thin vertical slice that exercises browser -> API -> DB -> response, even with ugly UI and stub logging. Once the slice is live in staging, return to polish. Horizontal work before the slice exists is risk accumulation with no mitigation.

Question 13: Scope-cut rule invocation​

Your cut-rule says: "end of week 3, MVP not deployed to staging -> cut column clustering." It is end of week 3, and the MVP is not deployed. You feel column clustering is "just one more day" away. Do you cut, and why?

Answer: Cut. The rule was written when you were not tired and not invested. The week-3 self who feels "one more day" is the self the rule protects against. Cutting column clustering removes one source of slip and makes the rest of the schedule credible. If you renegotiate now, the rule is dead, and no future rule will bind.

Question 14: Defense answer shape​

You are asked during the defense: "what would you do differently with more time?" Which of these three answers is best, and why?
(a) "Nothing major -- I think the architecture is solid."
(b) "I would rewrite the whole thing as services -- I really wanted to try that."
(c) "I would harden the broadcast path with a bounded per-client outbound queue. Today it is in-process fan-out; under real scale that would not hold. See ADR-001's 'premature at 20 users' line."

Answer: (c). It is specific, honest, tied to an artifact, and demonstrates engineering maturity -- you know the weakness and the reason you did not address it. (a) looks dishonest and untested. (b) sounds like you built the wrong thing. (c) shows you built the right thing for the scope and can describe the evolution.

Question 15: Risk-driven decision gate​

You have three candidate capstone problems. What single question do you ask of each to pick the right one? Justify the question.

Answer: "What is the scariest unknown, and can it be answered in week 1?" Justification: the capstone is won or lost on the top risk. A problem whose scariest unknown is answerable in week 1 is de-riskable; a problem whose scariest unknown is "I won't know until week 5 if the user cares" is an unfinishable capstone. The risk gate beats enthusiasm, stack familiarity, and grade-potential as a selector.

Interleaved Review Questions​

Prior Module Question 1 (from S7 M01 Architecture Fundamentals)​

What makes an architecture characteristic "implicit" versus "explicit," and why does it matter for your capstone's design doc?

Answer: Implicit characteristics are ones the user assumes (it must not lose data, it must not crash) but the architect did not name. Explicit characteristics are the top-3 drivers written in the design doc. For the capstone, every implicit characteristic is a landmine -- it will be violated silently. The design doc's "non-goals" section is exactly where you make the implicit ones explicit.

Prior Module Question 2 (from S7 M03 DDD)​

What is the difference between a bounded context and a module?

Answer: A bounded context is a strategic-design concept: a region of the domain where terms have a single, consistent meaning. A module is an implementation-level unit of code. A bounded context may map to one or more modules. Terms drift across contexts, which is why ubiquitous language is per-context.

Prior Module Question 3 (from S7 M05 ADRs)​

Why does an ADR's "consequences" section need to name negative consequences, not just positive ones?

Answer: Because the goal of an ADR is to let a future reader argue with the reasoning. An ADR with only positive consequences looks like advocacy, not engineering. The negative consequences reveal the tradeoff the author accepted, which is the most useful information for a reader considering whether to change the decision.

Prior Module Question 4 (from S8 M01 System Design Methodology)​

When does non-functional requirements gathering feed into the architecture, versus vice versa?

Answer: Both directions, iteratively. NFRs constrain architecture (if availability is 99.99%, single-instance is ruled out). But a chosen architectural approach also reveals new NFRs (using WebSockets introduces a reconnect NFR that was not obvious beforehand). The design process must let the two shape each other, not pretend one fully precedes the other.

Prior Module Question 5 (from S6 M05 Distributed Systems Fundamentals)​

What is the single most common reason to avoid distributed systems at capstone scale?

Answer: The network is unreliable, and every distributed component introduces partial failure modes (timeout, partition, retry, idempotency) that eat engineering budget. At capstone scale, there is no characteristic in the top-3 that a single process cannot satisfy, so the cost of distribution has no offsetting benefit.

Self-Assessment and Remediation​

Mastery Level (90-100% correct):

  • Ready. You can frame, decide, document, and defend a capstone architecture.

Proficient Level (75-89% correct):

  • Review the cluster whose questions you missed. Re-do the corresponding practice page. Re-rehearse the defense for that area.

Developing Level (60-74% correct):

  • Return to the concept pages in the weak cluster. Re-run the corresponding practice lab. Do not start Module 2 until at 75%+.

Insufficient Level (<60% correct):

  • You have not internalized the capstone-framing habits. Revisit S7 M01 + S7 M05 first, then all five clusters of this module, in order. Take the quiz again.